ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurd...@apache.org>
Subject RE: [myrmidon] Move framework outta myrmidon?
Date Wed, 03 Apr 2002 11:35:07 GMT


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]

> 
> On Thu, 28 Mar 2002 16:02, Adam Murdoch wrote:
> > > hmmm. I didn't notice that. Was this something you added? In
> > > theory it could
> > > completely be removed because I can't see how you would want 
> to use it as
> > > DataTypes are not likely to match the role unless they were
> > > registered under
> > > role in which case the next bit of code will never get executed.
> > >
> > >  // Use the generic 'data-type' role.
> > >         final TypeFactory factory = m_typeManager.getFactory(
> > > DataType.ROLE );
> > >         if( !factory.canCreate( name ) )
> > >         {
> > >             throw new NoSuchPropertyException();
> > >         }
> > >         return factory.create( name );
> > >
> > > So can't we just delete that code ?
> >
> > It's used for 2 (experimental) cases, that are kinda handy:
> >
> > * Where the add() method's type does not map to a role type, 
> data-type is
> > used as the role.  This means you don't have to create a role, 
> and can just
> > use plain data-types instead.
> 
> Really don't like that use ;) Seems like an ugly hack. Either it 
> is pluggable 
> or its not. And if it is pluggable we want it to be as strongly typed as 
> possible (ie it implements the correct interface) and all objects that 
> implement a role interface should register themselves under that role.
> 

Fair enough.  I'm happy to axe that one.

> > * Allows you to use a plain data-type as a nested element 
> instead of a role
> > type, and the configurer will attempt to convert it to the 
> expected type.
> 
> Hmm not sure what use this is. If you wanted this behaviour why 
> not just add 
> in something like
> 
> addName( MyType myType )
> 
> ? 
> 
> I think I must be missing something.
> 

It's handy for evolution, since:

* The container type doesn't need to know anything about the source type.  This lets you,
for example, add new nested elements to a container type that you don't control the source
for, and where polymorphism won't work (like, say, where you don't control the source for
the source types either).

* The conversion is decoupled from both the container type and the source types.  This means
that you can easily replace the conversion.  It also is useful for bridging between 2 polymorphic
type hierarchies.

Having said that, implicit conversion might be a bit too much.  For one thing, the above things
can be done using an explicit adaptor type.  It also blurs the namespace of nested elements,
since any datatype can be used (which makes error reporting a little harder).

If we were to remove this, I wonder whether we should also get rid of implicit conversion
of references too?


> > It *does* encourage bad practice.  What we need is a solution that sits
> > somewhere between the extremes of no sharing, and opening up 
> everything. 
> > Some controlled sharing would be a good thing.  For example, we want the
> > stuff in the ant1compat antlib to be visible to those antlibs 
> that need it,
> > without making it visible to everything.  Same is true of a lot of the
> > stuff in framework.
> 
> True. Hmm ... I really think that the extension mechanism can be 
> made to do 
> this. I really don't want users having to worry about mucking 
> about with all 
> this stuff. It may be an absolute PITA for us to code it but I 
> think that is 
> better than making users suffer. 
> 

Yep, +10000 for pushing complexity into the engine.  Of course, we shouldn't forget that task
writers are users as well.  Whatever we come up with needs to be easy to write antlibs against.


> How about we try enhancing the extension / classloader system so 
> that we can 
> have multi-parent classloaders (assuming disjoint class sets). 
> The we try and 
> build an appropriate dependency tree for each library dependency 
> tree. if we 
> detect conflicts (ie dependency 1 uses X lib in classloader A while 
> dependency 2 uses X lib in classloader B) then we throw an 
> exception and hope 
> things work out for the best ;)
> 

I just checked in a bunch of changes to do this.  Let's see how it goes ...


> > We can do this to some degree by fixing up the handling of extensions
> > (resolving them for jars in lib/, fixing up the classloaders, 
> and so on). 
> > I'm not sure how this will go long term.  In particular, what 
> would be nice
> > is if an antlib writer could distribute a single .atl file, 
> rather than a
> > .jar that has to get installed in ${myrmidon.home}/lib, one 
> that has to get
> > installed in ${myrmidon.home}/ext, and an .atl that has to get 
> installed in
> > the antlib search path somewhere.
> 
> Yer. needs redoing. I need to redo it in phoenix aswell and may 
> try tackling 
> them both at the same time. Then again I am not sure when I can 
> get to it. 
> For the time being my main aim is breaking down the build system and 
> documentation. 
> 

Any thoughts on how it might be redone?

One simple option I was toying with, was to add a 'final' attribute to the antlib descriptor.
 Antlibs that are declared final cannot be used by other antlibs.  Non-final antlibs would
be made available as extensions that can be used by other antlibs.

This would (kinda) handle the main antipattern we're trying to solve, which is where the classes
in an antlib are used directly, where they weren't intended to be by the antlib writer.


Adam


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