You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Zeigermann <ol...@gmail.com> on 2005/01/23 19:33:06 UTC
Re: [contract] Suggestions
On Sun, 23 Jan 2005 15:19:51 -0800, Anaximandro (Woody)
<ag...@globo.com> wrote:
> 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. Specifying everything in Java does
not require to learn any new language and makes debugging very easy.
> 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?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [contract] Suggestions
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Sun, 23 Jan 2005 17:49:39 -0800, Anaximandro (Woody)
<ag...@globo.com> wrote:
> >> > 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?
Not suggesting, just mentioning as an option.
> >> 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
[snipping code samples]
Well, this is another language, isn't it? Semantics are the same, but
syntax is different and new. And even more verbose, right?
> >
> >> > 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!!!
Yes, OCL is a good example, I agree. I know there already are some OCL
parsers, but I do not know if there are any that have a licence that
would allow incorporation into contract.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [contract] Suggestions
Posted by "Anaximandro (Woody)" <ag...@globo.com>.
>> > 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