ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: IntrospectionHelper request
Date Fri, 11 Jan 2002 02:27:52 GMT
On Fri, 11 Jan 2002 12:05, Jose Alberto Fernandez wrote:
> > > The problem I have with this is that it allows a Task to violate all
> > > and any rules.
> >
> > precisely. It is the "escape and do whatever you feel like" bit so that
> > people can do whatever they feel like doing and still run it inside ant
> > with out messing up the container for other tasks.
>
> I think I am against unbound flexibility. I would argue that the job of the
> Configurer (to give it a name) is to maintain a minimum set of rules of
> behaviour. Once you start given away control in an unbound way there is no
> way back. Remember, that part of the aim in ANT2 is to allow people to
> write and distribute their own tasks. We cannot just say that we would tr
> to keep a lit on it.

Perhaps but a lot of people have complained that they want to do X in ant. 
Where X is some new thing which the majority of ant-dev  dont want to 
support. ie you and foreach or other people and X.

This just gives them a route to do it - now ant-dev wont have to block it - 
the other people can support their own task fully and it will hopefully not 
cause us any issues.

So can bad stuff be done with this? definetly. 
Do some people want to do bad stuff ? yeppo
Does ant-dev need to support any of this bad stuff? nope.

So hopefully ant-dev are less likely to be thought-police and more likely to 
people providing a platform - if other people want to do things we consider 
absurd - fine - they will need to support themselves though ;)

Almost everything in myrmidon is designed to be pluggable and allow people to 
do whatever they want - the only exception being policy (ie are properties 
immutable etc) and that is mainly as I never got around to changing it ;)

> > >I think the container (via an enhanced Introspection) needs to
> > > be the one in control here. By enhanced I mean that the work is not
> > > only based on Class introspection, but the Task is allowed to say what
> > > is willing to accept (what we have been talking about DynamicTask
> > > providing their own introspector).
> >
> > I await your fleshed out proposal. I haven't found anything that is both
> > easy and as flexible as the described approach.
>
> OK, I finally took a quick look at some of the interfaces of Myrmidon and
> here is a more concrete proposal. So what I am saying is to allow Tasks
> to provide their own ObjectConfigurer to use by the DefaultConfigurer.
>
> Instead of passing the configuration to the object if the Task implements
> Configurable, what you do is ask the Task to provide an ObjectConfigurer
> if the Task defines DynamiclyConfigurable (for example):
>
>     interface DynamiclyConfigurable {
>         ObjectConfigurer getConfigurer();
>     }
>
> For what I see of the the definition of ObjectConfigurable is should be
> quite easy for an object to define its own methods, and if we provide a few
> predefined helper classes, the whole affair could be even more trivial.

I don't see how this is any better or worse than what is already there ? 
Whats to stop a programmer doing evil things with this? Why is this any 
inherently better than the way it is currently done?

> Well, this is one reason I do not like auto-installation of libraries. One
> should declare the libraries that one want to have available to the build.
> As with java extensions when you allow auto-installation, the result is
> unpredictable behaviour.
>
> As for clashes, there are several things that need to be done:
>
> 1) Buildfiles should execute on a stable environment i.e., no auto-install
> but all libraries (appart from core) should be declared on the buildfile.
>
> 2) The container should detect clashes by looking at all possible role
> registries that may apply. This can be done quite efficiently.

+1 to all above (though I believe other committers have -1'ed it in the past) 
- however this does not stop libraries adding types unless you do the 
equivelent of single imports for every type you use which may be somewhat 
painful.

> 3) A clash resolution mechanism should be provided, posibly using aspects
> to indicate the expected role to be used in a particular occurrance.

I can't see how this would work. Could you explain it ?

> We have voted for and against so many things that are now part of ANT that
> I do not think the issue should be the vote but the technical merit of the
> approach. And then we can vote again (the commiters I mean).

true the votes mean nothing but I don't think the vote on that particular item is likely to
change ;)

> > Im not sure what the advantage of this. How is it any different to
> >
> > <role name="task" interface="org.apache.ant.TaskModel"/>
>
> The diference is that here you are indicating that all <task> should
> implement TaskModel, which is wrong. <task> implement Task, but the
> container needs to interpose a TaskModel between the two.
>

Still lost me - explain in code speak how you would write such a task.

> Well, what I am refering to is how the TaskModel captures the XML that
> defines it. We are probably talking about quite similar thins here. The
> only difference may be that for me TaskModel contains only the little piece
> of the XMLModel that corresponds to a particular Task (to each
> add(TaskModel) operation) and not one object for the entire Task being
> configured (which iswhat you do with Configurable).

Each COnfiguration object represents an XML fragment. It depends on the task 
to interpret it - it could be a task but it also could be a datatype or 
something else.

> I really do not thing Myrmidom is too far from what I am proposing.

I don't think so either except for that interspicing of TaskModel thing which 
I don't quite understand yet ;)

-- 
Cheers,

Pete

----------------------------------
   "Don't play dumb with me. 
I happen to be an expert at that" 
           - Maxwell Smart
----------------------------------

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