>> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
