Re: String -> Ressource

[Stefan Bodewig <bo...@apache.org>]

On Fri, 23 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@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 ...

> 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>

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 ;-)

>> 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.

Stefan

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

Re: String -> Ressource

[Stefan Bodewig <bo...@apache.org>]

On Sat, 24 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
> 
>> On Fri, 23 Mar 2007, Matt Benson
>> <gu...@yahoo.com> wrote:
>> > --- Stefan Bodewig <bo...@apache.org> wrote:

>> 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.

Later in my post I already agreed it would be simpler to do it that
way than try to resolve a ressource and fall back to File at the time
we want to execute the setter.  We agree by now.

>> >> bikeshedding? 8-)

> <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,

You said:

>> >> > 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.

Which I read as "I'm, not sure what the right color of the bikeshed is
and IMO this is the only outstanding question stopping us from
building the bike".

Again, I was joking.

>> >> 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.

8-)

So simply go ahead, implement the Ressource as an attribute stuff
using your preferred trigger and maybe have a vote if anybody objects.

Stefan

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

Re: String -> Ressource

[Matt Benson <gu...@yahoo.com>]

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

> On Fri, 23 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
> > --- Stefan Bodewig <bo...@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