Re: Getting the filename from a property

[Diane Holt <ho...@yahoo.com>]

--- Erik Hatcher <ja...@ehatchersolutions.com> wrote:
> Your examples are working within what you've been given with the current
> version of Ant, and you are dealing with a "file" as if its a string,

Actually, I thought I was working with a file -name- as if it's a string,
which, coincidentally, it is. :)

> My blue-sky syntax, ${property,file,basename} is not scripty really,
> its saying that the underlying type of property is really and truly a
> file and just "formatting" the output as the base name, for example.

But it seems more scripty to me than current Ant lingo, since it doesn't
spell anything out. One thing you can definitely say about Ant is that
it's anything but terse -- ask anyone who's ever put together three
different targets because they can't say <target if="foo=bar" .../>

> Its not scripty to ask <tstamp/> for a date in a particular format -
> just a different visual representation of the same underlying thing.

But it's the very "visual representation" that makes yours seem scripty
(for Ant). I mean, if you want to make <property> more of a work-horse,
and have it deal with things like being told, eg., "consider this property
I'm derefencing as type 'file', retrieve its basename, and apply it as the
value of this new property I'm defining", that's okay -- but in order to
keep that functionality in line with how Ant currently goes about
representing that sort of thing, it seems to me it should be done with
attributes and nested elements.

> You're without a doubt a Unix shell scripting wiz.

Without a doubt -- but that's only because I happen to be a wiz at just
about everything :) 

> And you're not a Java programmer by day like most of the rest of us
> (self-confessed).

True -- at the moment, I'm not any kind of programmer by day (but if I
don't win the lottery soon, I may well need to go back to being one :)

But you shouldn't limit it just Java. I have no background in OO stuff at
all -- I started with BASIC (for a couple of days, to get the gist of what
"programming" was), jumped to assembler, then finally settled into C.

> Agreed.  I want <script> to be just like a task.

What is it you think it currently is? I've never seen it as anything else.

> Its our job to get those representations right so that a build file
> reads like someone telling you the steps of the build process [...]

But that was my point from the beginning -- that your proposed syntax
doesn't "read".

> And those same people that can't write a new task shouldn't be
> writing <script> either since they are essentially the same thing (even
> in your own words).

Can't agree there. If the pat answer for someone needing some new
functionality is going to be "write a task", and the person doesn't know
Java, but they do know one of <script>'s supported scripting languages,
then a script for <script> is exactly what they should be writing.

> And I agree with you, when there is no other option, its time to hack
> and make do with whats there - not any argument there.

Can't agree with you here, either -- I don't know what "hack" you think
has been getting done. I certainly don't see using the <script> task as a
"hack".

Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

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

Re: Getting the filename from a property

[Erik Hatcher <ja...@ehatchersolutions.com>]

----- Original Message -----
From: "Diane Holt" <ho...@yahoo.com>

> > My blue-sky syntax, ${property,file,basename} is not scripty really,
> > its saying that the underlying type of property is really and truly a
> > file and just "formatting" the output as the base name, for example.
>
> But it seems more scripty to me than current Ant lingo, since it doesn't
> spell anything out.

You and I have far different definitions of "scripty" then.  Spelling it
out, to me, is "scripty" in that you have to manually write all the petty
little details to get the basename - search for the last file separator,
strip from there forward, etc.  Writing explicit steps (i.e.
non-declarative) for routine things is what Ant is trying to avoid.
Otherwise we'd all be writing .sh scripts for our builds!  :)

> One thing you can definitely say about Ant is that
> it's anything but terse -- ask anyone who's ever put together three
> different targets because they can't say <target if="foo=bar" .../>

With <condition> its not necessary to have as convoluted stuff any more.

> But it's the very "visual representation" that makes yours seem scripty
> (for Ant). I mean, if you want to make <property> more of a work-horse,
> and have it deal with things like being told, eg., "consider this property
> I'm derefencing as type 'file', retrieve its basename, and apply it as the
> value of this new property I'm defining", that's okay -- but in order to
> keep that functionality in line with how Ant currently goes about
> representing that sort of thing, it seems to me it should be done with
> attributes and nested elements.

Now you're getting warmer!  But I'm not suggesting any such addition to
<property> - it does enough as it is.  I'm actually not even proposing any
implementation at this time... simply arguing that Ant should be cleaner
than the kinds of workarounds it took (past tense now that you're adding
those two new tasks!) to get such obviously important things like pieces of
a filename.

> > Agreed.  I want <script> to be just like a task.
>
> What is it you think it currently is? I've never seen it as anything else.

Well, Conor's version is what I'm talking about.  The current <script>
cannot take nested filesets, nor can it accept attributes like a "real" task
can.  So while <script> itself is technically a task, the code you write
inside of it is not the same as what you'd write inside execute() of a Java
task.

    Erik



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