ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [PATCH] Script enhancement to standardize the "project" object exposed
Date Sun, 30 Sep 2001 04:04:49 GMT
On Sun, 30 Sep 2001 13:25, Erik Hatcher wrote:
> The <script> task seems to be designed for ad hoc task creation, so why
> shouldn't it act just like being in the execute() method and have the same
> capabilities?

Who saids it shouldn't?

> JavaScript does not itself have a way to print that I know of - it relies
> on provided objects to do so ('alert' in web browsers to pop up a dialog
> box). I believe (and please correct me if I'm wrong) that to do a
> System.out.println from JavaScript you'd have to get a handle to the System
> object.

Hmmm - I thought you could access java objects directly in BSF. Something 
like prefixing it with "java." or similar. Not sure. If not then feel free to 
send a patch that places a reasonable adaptor object that looks like

class Logger


Any other reasonable abstractions will also be considered if you need access 
to other things.

> But you're arguing against capability that already exists, just in a more
> obtuse way.   Tasks, Targets, Project, and Properties are all accessible
> already, just not cleanly.   All I'm asking for is a known name to access
> the enclosing task.

I like that it is obtuse because that means less people will use it and thus 
less people will complain when we break compatability with ant2.

> What functionality do you see <script> providing?    I view it as a way to
> write a Task without having to create a Java class, compile it, and
> <taskdef> it.   I view it simply as the implementation of the execute()
> method of Task, and in that light I think it should be able to have clean
> access to the Task object.

Doing this would mean that we are guarenteeing that we break compatability 
with future iterations of ant. Do you see this as a good thing?

> The same argument applies to the Task though, and that was my point.  Task
> makes even more sense to me than Project.  <script> *is* a task.   It is
> simply the implementation of execute().   Shouldn't it enjoy the same
> privileges that a Java Task enjoys with easy member access?   Shouldn't we
> just view the <script> code as execute()?

Some functionality would benefit to be added for usability sake. However this 
is not the thing I dislike - It is binding to implementation specific objects 
that will mandate that we break compatability in future that seems kinda 
foolish to me. Sure it is already accessible but it is obtuse enough that 
most people will not use it and thus it will be easier for use to support in 

> I've never seen so much discussion over one line of code before!  :)

The line of code is almost irrelevent - it is the concept. Should we be 
making changes to ant now that will make it easier to write build files that 
will break in the future?



 Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is 
the task of journalists and historians to rectify 
this error."

View raw message