commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anaximandro (Woody)" <agodinh...@globo.com>
Subject Re: [contract] Suggestions
Date Mon, 24 Jan 2005 01:49:39 GMT
>> > Daniel, what dou you think about put constraints rules on some type of
>> > propertie file? These constraints must have some type of identification
(in
>> > one ore more contexts). This is flexible and make the code more clean
(and,
>> > like ejb, can be changed without the need to recompile the code).
>> I guess it would have been an alternative to use meta information tags
>> using @ in Javadocs as well. However, I understand that Daniel did all
>> this as a philosophical decision.
>   more one javadoc tag? I dono, are you suggesting to use the own source
>   code as a propertie file or generate another source like xdoclet does?

>> Specifying everything in Java does
>> not require to learn any new language and makes debugging very easy.
>   I dont't agree with debugging facilitie you told. Debug more code is
more
>   hard than debug less code. Don't have to learn another language to use
>   the library is a facilitie, I agree, but I´m not talking about another
language,
>   I´m talking about another way, more easy and flexible, to do the same
>   thing. By example:

<?xml version="1.0"?>
<contract>
  <extend>../another/contract.xml</extend>
  <name>Contract Sample</name>
  <id>sampleContract</id>
  <currentVersion>0.1</currentVersion>

  <constexts>
    <context>
      <name>SpeedCalculator</name>
      <id>SpeedCalculator</id>
    </context>
  </contexts>

  <constraints>
    <constraint>
      <name>distance</caption>
      <id>distance</id>
      <type>java.lang.Number</type>
      <nullable>false</nullable>
      <default>0</default>
      <minvalue>0<minvalue>
      <maxvalue>999999<maxvalue>
      <inclusive>true</inclusive>
      </constraint>
    <constraint>
      <name>unit</caption>
      <id>unit</id>
      <type>java.lang.String</type>
      <nullable>false</nullable>
      <domain>
        <value id="h" caption="h"   comment="hours"/>
        <value id="m" caption="min" comment="minutes"/>
        <value id="d" caption="s"   comment="seconds"/>
      </domain>
      <default>h</default>
      </constraint>
    <constraint>
      <name>time</caption>
      <id>time</id>
      <type>java.lang.Long</type>
      <nullable>false</nullable>
      </constraint>
  </constraints>

  <parameters>
    <parameter>
      <caption>distance</caption>
      <id>distance</id>
      <type>java.lang.Number</type>
      <contraint>distance</constraint>
      </parameter>
    <parameter>
      <caption>unit</caption>
      <id>unit</id>
      <type>java.lang.String</type>
      <contraint>unit</constraint>
      </parameter>
    <parameter>
      <caption>time</caption>
      <id>time</id>
      <type>java.lang.Long</type>
      <contraint>time</constraint>
      </parameter>
  </parameters>

  <results>
  </results>

</contract>

with this contract defined I think in this code:

    public Number speedCalculator( final Number distance, final String unit,
final Long time ) throws ContractException {

        final String context = "speedCalculator";
        final Contract parameters = Contract.getInstance().getContext(
context ).getParameters();
        final Contract result = Contract.getInstance().getContext(
context ).getResult();

        float distance = ((Number) parameters.set(distance));
        String timeUnit = ((String) parameters.set(unit);
        float time = ((Number) parameters.set(time));
        parameters.verifyContract();

        float speed;
        if (timeUnit.equals("s"))
            speed = distance / time;
        else if (timeUnit.equals("min"))
            speed = distance * 60 / time;
        else
            speed = distance * 3600 / time;

    // I dono if I really need to check result
        speed = ((float) result.set( speed ));
        result.verifyContract();

        return speed;
    }

>
>> > Do you know OCL?
>>
>> I think it would be suitable for describing those contract
>> information, but wouldn't this require some sort of OCL parser and
>> then engine? Wouldn't this be out of scope for a simple tool like
>> this?
>
> I agree, make a OCL parser is out of THIS scope. In fact we don't need all
ideas in
> OCL but I think is a good start point to study right? Is there any OCL
parser
> implementation? No? Cool!!!

Woody


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message