Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <20050408140501.5721.qmail@web30908.mail.mud.yahoo.com>
Date: Fri, 8 Apr 2005 07:05:00 -0700 (PDT)
From: Matt Benson <gudnabrsam@yahoo.com>
Subject: RE: ResourceCollections
To: Ant Developers List <dev@ant.apache.org>
In-Reply-To: 
 <A672996F85AA7240A9DD2A455BD0D428FA66FE@HOUEXCH902.Landmark.lgc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

This was so well put-together I have little to add,
though I will say that after having had time to absorb
Peter's proposed alternative container, I am probably
not as negative about about it as Dominique.  The
point that this type of fix would require maintenance
however certainly seems valid.  My only other question
would be, what was the intent of reserving the "ant:*"
namespace "protocol" in the first place?

-Matt


--- Dominique Devienne <DDevienne@lgc.com> wrote:

> > From: Peter Reilly [mailto:peterreilly@apache.org]
> > I do not like "ant:mappers", etc
> 
> I don't have much of a problem with it myself now.
> It's been argued, winning me over, that the ant:
> prefix
> is already reserved, and thus it's an acceptable
> solution
> solution to this problem, and Matt idea of loading
> role.xml
> for ant:<role> is elegant enough, no?
> 
> > This does not use the method "antlib:<package
> name>" that antlibs
> > are meant to be identified by. If "ant:<whatever
> core wants>" is
> > used to identify ant's antlibs', then there is
> ample reason for
> > thirdparty antlibs authors to ask for "easy to
> use" XML uri
> > identifications for their antlibs.
> 
> As I wrote earlier I also like the antlib:<package>
> convention.
> That's what I proposed we used in the first place.
> But others
> think it's too verbose. Surely you can see where
> they're coming
> from Peter ;-)
> 
> > For core ant types, I do not think it is a good
> idea - the namespace
> > syntax will "get in the way".
> 
> Not really. Within Ant itself, you would never need
> to specify
> NS for mappers, selectors, etc... Because Ant types
> using them,
> instead of having one elegant add(FileSelector)
> method, they have
> tons of add<this>(FileSelector).
> 
> The need for namespaced types arises for 3rd party
> which do use
> the more elegant and extensible add(Type) methods!
> 
> Use a namespace is tons more elegant than having to
> explicitly
> typedef each one you want to use like I had to do.
> If you refuse
> to add role-specific antlibs, then I'll have to
> define them
> myself in my custom AntLib, which clearly breaks
> encapsulation.
> 
> > For about a year now, new mappers, conditions,
> selectors and filters
> > have been added by making them typedefs.
> 
> If so, why did I need to typedef the date and size
> selectors
> when I'm using Ant 1.6.2?
> 
> > We should be able to make all the current
> conditions, selectors and
> > filters be typedefs.
> 
> But then you're polluting the global namespace IMHO.
> 
> Types where originally for elements that could stand
> on their
> own at the top level, or directly inside targets.
> All these
> new types you are defining in the global namespace
> OTOH are
> meant to be used only in a very narrow context,
> within another
> (real) type or task.
> 
> > There are only a few name over-laps:
> >    and, or, not  (selectors and conditions)
> > 
> > Of course this will change with the selectors for
> the
> > new resource collections,  - but it may be
> possible to
> > be clever.
> 
> Precisely. We already have name conflicts, and it
> will
> only get worse. Namespaces are meant to resolve name
> conflicts. Lets try to not get too clever trying to
> implement another mechanism for this.
> 
> > It is quite easy to write a type that is a
> container for
> > selectors and conditions (attached) that will act
> as a
> > container for selectors or for conditions.
> 
> It's my turn to not like this. As you say, it's
> clever,
> but now you're writing code to disambiguate name
> clashes,
> and the more name clashes appear, the more you write
> code...
> 
> 
> So to summarize, you Peter don't need to use any
> namespace
> when using Ant roles, because you're likely to use
> then in
> the context of Ant types/tasks, which have
> specialized add
> or create method for them.
> 
> I, otoh, but using the new flexible add(Type)
> method, have
> forced to use namespaced Ant roles (mapper,
> selector), and
> that's perfectly alright with me.
> 
> It is my opinion that Ant roles should *NOT* be
> added as
> types (if some were, then for BC reason they can
> stay that
> way, but only if they appeared in an official
> release), to
> avoid polluting the global namespace.
> 
> As a consequence, like I said in the first place, we
> need to
> define Role-specific AntLibs (and thus namespaces).
> And I
> personally don't care if we use ant:<role> or
> antlib:<package>.
> What I wanted in the first place, and still want
> obviously,
> is for these to be defined, so I don't have to
> explicitly
> typedef myself pre-defined Ant role impls in my
> build script.
> 
> If somehow we go your proposed put-them-all-as-types
> route,
> then I also won't have to typedef them explicitly,
> which I
> like, but we haven't resolved the name conflicts at
> all.
> And your proposed clever solution to this is not an
> acceptable
> solution to me (at this point).
> 
> The ideal solution would be in fact to allow
> registering
> several classes/types under the same name, and the
> Ant runtime
> to pick the one type for which isA(Type) is true,
> fort the Type
> at hand, failing with an Ambiguous error if more
> that one such
> type exists. This way, you could register
> AndSelector and
> AndCondition with <and>, and use the 1st in the
> context of
> add(FileSelector), and the 2nd when with an
> add(Condition).
> This doesn't eliminate all conflicts, as for example
> your
> ContainerConditionOrSelect has both, it would be
> Ambiguous
> still.
> 
> To me, using role-specific AntLibs is simply the
> only foul
> proof solution to name conflicts, that fits the
> existing
> behavior of Ant. --DD
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 


__________________________________ 
Yahoo! Messenger 
Show us what our next emoticon should look like. Join the fun. 
http://www.advision.webevents.yahoo.com/emoticontest

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