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
{
debug(message)
info(message)
error(message)
}
etc.
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
future.
> 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?
--
Cheers,
Pete
------------------------------------------------------
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."
------------------------------------------------------
