--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> > > Alexey N. Solofnenko wrote:
> > > Recent trunk ANT fails in my builds.
> > > <condition property="test">
> > >   <scriptcondition language="jython"><![CDATA[ #
> test
> > >     self.log("test")
> > > ]]>
> > >   </scriptcondition>
> > > </condition>
> >
> > Matt Benson wrote:
> > Fairly recently I added return handling to
> > scriptcondition from the perspective that it was
> more
> > natural to treat the whole construct like a
> function...
> 
> Well, what's the point of such a scriptcondition
> Alexey?
> scriptcondition should return a boolean value (or
> something than can
> be "cast" to a boolean somehow), and Matt's change
> sounds completely
> reasonable to me. Breaking BC when for conditions
> that don't make
> sense (to me) since not returning a value is fine by
> me. Am I missing
> something?
> 

<scriptcondition> originally behaved such that a
default value can be declared on the task as an
attribute, and the embedded script can set the
condition value.  I preserved this behavior, but added
a preference for a return value, if any, from the
script:  again, on the basis that this seemed a (more)
natural behavior to me.  DD, you said "not returning a
value is fine by you"... and that's what
<scriptcondition> always did, and _should_ still
allow... am _I_ missing anything (other than whatever
I've apparently done to break python compatibility)?

-Matt

---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



      
____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to