ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: override
Date Wed, 06 Aug 2003 12:16:45 GMT
> From: Costin Manolache []
> Jose Alberto Fernandez wrote:
> > 1) I should be able to determine the correctness (loosely 
> used here) of a
> > buildfile by looking at that buildfile (and its dependencies) in
> > isolation. This means that the fact that I am imported by 
> someone else
> > should not affect my correctness (modulo overriden targets).
> > 
> > Rewriting of targets, may attempt at this correctness.
> > 
> > How can we get something more interesting out of that 
> principle above, I
> > agree is quite generic. Lets see...
> Does it mean the imported buildfile needs to behave in the 
> same way if it
> is used standalone or imported ? ( which implies all 
> resolutions should
> be based on the imported file, etc ) ?

No, we are not talking about behavior but correctness (;-/)
What I mean is that the targets that need to be executed must be
well defined from the point of view of the file, what the targets
will do depends on the overriding and visibility constraints
that you have overall. Just like when you analize the correctness
of a class in OO which may be extended in the future.

> > 2) It would seem we need to be able to specify whether a 
> target can be
> > overriden or not. We need to be able to define if a target 
> is: private,
> > final, or overidable. Notice that this is a property of the 
> target and not
> > of the way the target is imported.
> Can you explain a bit more why a build file needs private or final ?
> I think if the syntax/semantic for the build file gets more 
> complicated than 
> the syntax for java, we are in trouble :-)

Well, this is just like Java :-)
Couldn't find a usage for "protected" though.
My point is that you need to be able to say, people cannot
mess-up with this target (because the build depends on it as is)

Although I am not following the Java model to the letter
(but Java does not have multiple inheritance), there are
two separate objectives that Java solves separately:

1) Visibility: private, package, protected, public.

2) Overridability: private or final, not-final.

Notive that all private methods are by nature final, hence accessability
and visibility meet at that point. I tried to put the two toghether
to simplify so you have for targets:

	private, final (final and public), and overribable (just public)

The concept of Package makes no sense for us, which leaves protected
as something to consider. "protected" could be use to say that
importing files can see it (and override them) but parallel imports
will not see it. It will forbid a target from one fragment to clash
or be used by some other fragment also being imported.

With this concepts you have control at the target level of the different
scenarios we want to cover. Which was another of my problems with the
other proposals, they were too blunt since they applied the same visibility
to all the targets on the import and there was no way to discriminate.

> > The meanings are:
> >  private ==> other targets with same name on other files will not
> >  override;
> >              any mention on dependencies on this file for 
> that target will
> >              use this private version;
> > the target is not visible from outside the file.
> > 
> >  final ==> target visible from other files but not 
> overidable, it is an
> >  error;
> >            any mention on dependencies on any file (without 
> a private def)
> >            uses this version.
> > 
> >  overridable ==> target visible from other files, and overridable;
> >                  any mention on dependencies on any file 
> will use top
> >                  level available version.
> > 
> > this are just suggestions, other levels of protection may 
> be possible.
> I hope not. This sounds far too complicated, close to a "flexibility
> syndrome". 
> One think I don't understand is why the import should be used as a OO 
> substitute. Most languages I know define the import in a much simpler
> way. Maybe I'm missing too much of the context, I'm still 
> trying to get
> updated with the mailing lists.
The current requirements for import ask for overridability of targets,
which means OO behavior. Since you can have multiple imports
you finish with possible multiple inheritance (definitions of the same target)
how do you solve it? It is the classical multiple-inheritance OO mess. :-(

Jose Alberto


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message