You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/02/17 07:39:16 UTC

Design By Contract

Hi,

It would be nice to optionally support this in phoenix at some stage ;)

http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-dbcproxy.html?

-- 
Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Design By Contract

Posted by Gerhard Froehlich <g-...@gmx.de>.


>-----Original Message-----
>From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>Sent: Sunday, February 17, 2002 2:52 PM
>To: Avalon Developers List
>Subject: RE: Design By Contract
>
>
>> From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
>>
>> Hmm I saw something in the book "Pragmatic Programmers", they used javacc
>> for this pre-compiling...would be fast...
>
>Unless I'm mistaken, they used IContract for the preprocessing.

I think you're right. I lend this book to a friend and I can remember lightly
that they used *something*. I think I mixed it up.

just ignore this posting...

  ~Gerhard

-----------------------------------
Boren's Law: When in doubt, mumble. 
-----------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Design By Contract

Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
>
> Hmm I saw something in the book "Pragmatic Programmers", they used javacc
> for this pre-compiling...would be fast...

Unless I'm mistaken, they used IContract for the preprocessing.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Design By Contract

Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,

>> > It would be nice to optionally support this in phoenix at some stage ;)
>> >
>> > http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-dbcproxy.html?
>>
>> +1
>> Hoewever, I think its more a framework level thing isn't it?
>
>perhaps - but it needs to be implemented by the container when components are 
>placed into the CM. So it could be implemented in either the ECM or the 
>phoenix container.
>
>> Secondly, while reading the article I noticed the use of @pre and
>> @post etc.  Currently in the Avalon javadoc there is intermitent use
>> of these "non-standard" declarations and resulting warnings when
>> generating javadoc under JDK 1.4.  Perhaps it would be a good idea
>> to change out current @pre to @avalon.pre to avoid furture
>> conflicts.
>
>Actually our current @pre* tags where when we were thinking about using 
>another DBC tool (IContract) but decided against it as it required 
>non-standard compiler.

Hmm I saw something in the book "Pragmatic Programmers", they used javacc
for this pre-compiling...would be fast...

  ~Gerhard
 
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It   |
| just happens to be selective on who it makes friendship |
| with.                                                   |
|                       - Richard Cook                    |
*---------------------------------------------------------*


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Design By Contract

Posted by Peter Donald <pe...@apache.org>.
On Sun, 17 Feb 2002 20:25, Stephen McConnell wrote:
> Peter Donald wrote:
> > Hi,
> >
> > It would be nice to optionally support this in phoenix at some stage ;)
> >
> > http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-dbcproxy.html?
>
> +1
> Hoewever, I think its more a framework level thing isn't it?

perhaps - but it needs to be implemented by the container when components are 
placed into the CM. So it could be implemented in either the ECM or the 
phoenix container.

> Secondly, while reading the article I noticed the use of @pre and
> @post etc.  Currently in the Avalon javadoc there is intermitent use
> of these "non-standard" declarations and resulting warnings when
> generating javadoc under JDK 1.4.  Perhaps it would be a good idea
> to change out current @pre to @avalon.pre to avoid furture
> conflicts.

Actually our current @pre* tags where when we were thinking about using 
another DBC tool (IContract) but decided against it as it required 
non-standard compiler.

-- 
Cheers,

Pete

*---------------------------------------------------------*
| Programming today is a race between software engineers  |
| striving to build bigger and better idiot-proof         |
| programs,and the universe trying to produce bigger and  |
| better idiots. So far, the universe is winning.         |
|                       - Richard Cook                    |
*---------------------------------------------------------*

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Design By Contract

Posted by Stephen McConnell <mc...@apache.org>.

Peter Donald wrote:
> 
> Hi,
> 
> It would be nice to optionally support this in phoenix at some stage ;)
> 
> http://www.javaworld.com/javaworld/jw-02-2002/jw-0215-dbcproxy.html?
> 

+1
Hoewever, I think its more a framework level thing isn't it?
Secondly, while reading the article I noticed the use of @pre and 
@post etc.  Currently in the Avalon javadoc there is intermitent use 
of these "non-standard" declarations and resulting warnings when 
generating javadoc under JDK 1.4.  Perhaps it would be a good idea 
to change out current @pre to @avalon.pre to avoid furture 
conflicts.

Cheers, Steve.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>