ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: String -> Ressource
Date Sat, 24 Mar 2007 14:32:54 GMT

--- Stefan Bodewig <bodewig@apache.org> wrote:

> On Fri, 23 Mar 2007, Matt Benson
> <gudnabrsam@yahoo.com> wrote:
> > --- Stefan Bodewig <bodewig@apache.org> wrote:
> 
> >> I guess we'd need something dynamic, i.e. there
> has to be a way to
> >> register a ressource prefix with RU so that I can
> have string
> >> representations for my own ressource types.
> > 
> > I had assumed we could specify things in such a
> way as
> > to specify the resource type simply by its
> typedef,
> 
> For some reason I never made that connection, even
> though it is
> obvious.  That's why I didn't see a conflict with
> XML namespaces
> either.
> 
> > but I suppose a shortcoming of doing it this way
> is
> > that for types from antlibs they must be
> explicitly
> > typedef'd or have their ns mapped.  Well, I
> suppose
> > e.g.
> > 
> > antlib:org.foo/customResource?bar
> > 
> > wouldn't be the end of the world,
> 
> I don't think it would be too much to simply require
> ressources to be
> typedef'ed if you want to use the String ->
> Ressource magic.
> 
> >> For BC we'd have to keep the File-argument
> setters anyway.  IH
> >> could be changed to use setSrc(Ressource) in
> favor of setSrc(File)
> >> and use the later if no ressource mapping was
> found.  No real need
> >> to have a default in RU.  OTOH it might be
> convenient for users
> >> when they can simply omit the "file?" prefix for
> files.
> >> 
> > 
> > That'd be quite a bit of IH modification to make
> it
> > preserve > 1 type for a given property.
> 
> Not that bad.  IH already favor setters for anything
> that's not a
> string over a plain String setter.  But IH already
> is a pretty complex
> beast ...

Right, the whole thing is it favors those non-String
setters once, for good and all, at construction.  So
by the time you're actually using it, under the
current implementation, your IH instance has already
made up its mind what type "src" is, and it would be
random if we don't at least go in and say Resource
trumps File.  It would take more surgery to make IH
store e.g. a map of property names to (map of types to
AttributeSetters); currently it maps name directly to
AttributeSetter.  Not impossible, but modifies the
original design enough that it really no longer makes
sense to throw out String either in that case.  You
see?

> 
> > I can't decide what would be the best all-around
> solution, but it
> > does seem that if we overloaded the same property
> setters with File
> > and Resource, it might be easiest overall to add
> explicit code that
> > setSrc(File) won't override setSrc(Resource) in IH
> (maybe no type
> > can override a Resource),
> 
> would be easy, similar code already exists in IH.
> 
> > then default to FileResources as planned.
> 
> OK.
> 
> >> > However I'm not sure what the RIGHT "trigger
> character" is and
> >> > IMO this is the only outstanding question
> stopping us from adding
> >> > this feature to Ant.
> >> 
> >> bikeshedding? 8-)
> > 
> > I get those little allegories mixed up.  Is that
> the
> > one where we can blab back and forth forever, but
> > ultimately whoever is doing the work can make the
> > choice?
> 
> Not really.  It means we might be spending too much
> energy on
> discussing minor details (the color of the bike
> shed) while there are
> bigger problems to tackle.
> 
>
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>
>

I've read that one.  So I wonder what's the one I
said, or did I make it up or put a few together?  ;)
 
> Even though you sounded as if the choice of
> character was the only
> thing that prevented us from implementing the
> feature, I was not
> accusing anybody of wasting our time.  I was joking.
> 
> > Actually, globmapper doesn't seem to support ?. 
> ;) 
> 
> Ack, I should have known that.  The regexp mapper
> does, though ;-)
>

Right, though for optional expression components
rather than as a single-character wildcard.  :)
 
> >> OK, what is left?  "#", "="?  Or
> >> "url(http://www.apache.org/)"?
> > 
> > I kind of liked the parentheses thing when I saw
> it...
> > I wonder if it looks too much like a method call.
> 
> parens might look strange when use in a regexp
> mapper, curly braces
> might be better and they don't even look like a
> method call.
> 

For arguments' sake :) {} appear to be used at least
in the java1.4 regexp package.  But we're talking
about mapper RESULTS ("to" attr) so that narrows
things considerably.  Maybe the choice of character(s)
will be a necessary evil in some contexts.

-Matt

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



 
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love 
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265 

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


Mime
View raw message