ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@imapmail.org>
Subject Re: Selectors documentation and a Reference bug fix
Date Thu, 09 May 2002 17:25:41 GMT
Hmm thought this had been sent days ago, was sitting in my outbox instead.

----- Original Message -----
From: "Bruce Atherton" <bruce@callenish.com>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Sent: Tuesday, May 07, 2002 8:07 PM
Subject: Re: Selectors documentation and a Reference bug fix


> Ok, a quick summary of the feedback I've received so far and the changes I
> will submit today or tomorrow barring arguments to the contrary.
>
> First, <selector> seems to be preferred and I like it better as well, so
> I'll change to that.
>
> Second, I haven't heard complaints about changing the names to drop the
> "select" suffix, so they are gone.
>
> Third, I've fixed both the errors in the HTML. Thanks for the catches,
> Diane and Stefan. Stefan, I wasn't sure exactly what you were referring to
> since I think the HTML for the example of <containsselect> has &lt;
> everywhere. On reflection, however, I realized you must be talking about
> the contents of the contains attribute which render as "<script". I
decided
> to drop the &lt; from that string as it muddied what was supposed to be a
> clear example.
>
> Then we have Rob's "tirade". Please, keep the tirades coming. The more
> feedback, the better the selectors will be.
>
> At 05:02 PM 5/7/2002 +0100, Rob Oxspring wrote:
> >Static Selectors:
> >This term rubs a little as a Java developer since the classes have
nothing
> >to do with the "static" keyword.
>
> Fair enough. Changed to "Core" in the documentation.

Cool.
>
> >Date Selector:
> >Not wanting to start any pro/anti american battles but I hate the
> >"MM/DD/YYYY HH:MM AM_or_PM" on so many levels (its a pet of mine).  I
think
> >the best option it probably to allow pattern= and locale= attributes ala
> ><tstamp/> and will happily send in a patch to do so (probably tomorrow
> >night) unless someone else beats me to it.
>
> I'm going to leave this one to you. If you do this, you should also take a
> look at the Touch task since I got the format from there. Sounds like a
new
> feature, though.

The date part of the touch task had bypassed me I'm afraid, I'll try and
look into both and do battle on the 1.5 front when code is ready though.  It
does make sense to include it though as it would make things more consistent
between tstamp / propertyfile / selectors (/ touch).
>
> >   However I'd also suggest that
> >the default format changes - standards are there for a reason and
although I
> >can't lay my hands on a copy of ISO8601, the format seems to be
> >"YYYY-MM-DDThh:mm:ss.sTZD" (http://www.w3.org/TR/NOTE-datetime).
>
> Hmm. This would be something to get right from the beginning, but I favour
> consistency with existing tasks for a default rather than an awkward (from
> the user's typing point of view) standard. Just my HO, though, I'm ready
to
> be shouted down.
I'd grudgingly give in to the consistency argument, although I think that a
less ambiguous format should have been used.  The "awkward standard" is a
flawed argument - it is inherantly biased/ subjective: "MM/DD/YYYY HH:MM
AM_or_PM" is just as akward for those of us that don't use it (or anything
like) by default, while YYYY-MM-DD etc is exteremely rarely confused.

>
> What would be really nice eventually is a date parser that handled any
> format you threw at it, much like the one many C projects have with the
> getdate.y yacc file. It can handle "yesterday", "5 days ago", "a fortnight
> ago", and "last february". It can also handle "2001-12-17", "12/17/2001",
> and even "17-12-2001". Of course, it can't disambiguate "01-02-03"
> automatically, but you could use locale or pattern attributes only if you
> needed them. Someday.

Maybe, but the "X [unit]s ago" style can be handled by using the timestamp
task for now and I'm sure it could easily be adapted to handle the "last" /
"next" options if desired.  All of these leave xml behind though, and are
extremely biased towards english.

>
> >Extend Selector:
> >Like "static selectors" the term doesn't gell well for me. I think its
> >because "extend" is a verb which doesn't match with the others,
alternatives
> >might be "extendedselector" or "customselector".
>
> Assuming no one complains, I'll make this <custom>.
Cheers

>
> >When fields:
> >And now we reach the bottom of the pile.  When faced with <date
> >datetime="06/18/1979 00:00 AM"/> I would assume that it is going to
select
> >files with exactly that date rather than anything before it.  I guess
> >"equal" is going to be the least used of the "when" possibilities but I
> >still feel its the logical default.  The argument makes sense to me with
> ><size size="1" units"Mi"/> too - seeing this for the first time I would
> >assume that we are talking exact matches rather than maximum. So how
about
> >changing these defaults to equal when faced the less/equal/more question?
>
> I could make this change, but I'm not partial to it. I hear what you are
> saying about expectations (and I've argued that Ant should act as a user
> expects as much as possible myself) but I'm not thrilled with making an
> unusual usecase the default. My inclination is to save the user from
having
> to type things as much as possible, even if it means forcing them to read
> the documentation.

I thought this would be the reply - I really think that ant is generally
very good at being verbose and descriptive in its syntax and it would be a
shame to let this slip by.  Taking another tack: if we don't want to use
equal as the default (being uncommon is a fair argument) then why choose
"less" over "more"? These strike me as equally common and so we'd only be
shortening the typing for half the cases.

The bottom line is that I think that people maintaining the code / script
being able to quickly understand it is far more important than the coder
typing less.  Maybe this is a case where no default should be given?

I guess we could do with thoughts / feedback from others really.

Rob



>
> Counterpoints and further feedback welcome.
>
> Thanks everyone.
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message