Jose Alberto Fernandez wrote:

> First I do not think I have all the answers, just to keep things in
> perspective. What I think I have is a set of principles that I think any
> viable solution should provide. Lets see if I can put them into words: ;-|
> 
> 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 ) ?


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



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



Costin


> On a project-fragment, any target dependency not defined in the fragment
> will be picked up from the visible targets, following the rules above.
> 
> I would suggest an attribute like:
> 
> visibility="final|private|overridable"
> 
> you may decide what should be the default.
> 
> 3) targets can be overriden using <target/> which replaces the target
> completely. Or using <override-target> which allows expressing
> dependencies on the overriden target. The syntax in the dependency list is
> to mention the name of the target itself n the list.
> 
>    <override-target name="compile" depends="precompile, compile,
>    postcompile"/>
> 
> The "compile" target in the dependency list refers to the overriden
> target. Notice that <override-target> requires target name to already
> exist and be overridable.
> 
> 4) To support multiple inheritance, I would allow defining a name for an
> import. This name is only visible locally and can be used to specify in a
> dependency list a target comming from an specific import. You can refer
> that way to any target visible from that <import> but you cannot refer to
> inner <imports> of those that have been overriden. You cannot use the
> notation to break the visibility rules.
> 
>   <import file="xyz" name="a"/>
>   <import file="qrs" name="b"/>
> 
>   <target name="compile" depends="a->precompile, b->precompile">
>     ....
>   </target>
> 
> If xyz uses some other import that it names q, I canot say
> a->q->precompile, because that violates the visibility rules defined in
> xyz that provided its own target a->precompile.
> 
> Ok, I will stop now, we can talk about implementation later.
> 
> Jose Alberto



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