--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Fri, 23 Mar 2007, Matt Benson > <[EMAIL PROTECTED]> wrote: > > --- Stefan Bodewig <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ____________________________________________________________________________________ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
