ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Louis BOUDART" <jeanlouis.boud...@gmail.com>
Subject Re: EasyAnt <use>/<extends> vs <import>
Date Mon, 10 Nov 2008 10:13:07 GMT
> <jeanlouis.boudart@gmail.com> wrote:
> > I'm not sure that adding an as-attribute make sense for <extends>.
> > In our POC you can "import" with <use> mode the same file with different
> > prefix. exemple :
> > <project name="Abstract-Module">
> > ...
> > </project>
> >
> > <project name="Concret-Module1">
> >   <use file="Abstract-Module" as "AbstractModuleConcret1"/>
> > ...
> > </project>
> >
> > <project name="Concret-Module2">
> >   <use file="Abstract-Module" as "AbstractModuleConcret2"/>
> > ...
> > </project>
> >
> > <project name="genericBuild">
> > <extends file="Concret-Module1"/>
> > <extends file="Concret-Module2"/>
> > </project>
>
> What I've argued before is that the 'as' attribute used by a build
> should only be visible to that build. Any other build that uses it
> (English meaning of use :) should not be aware of this attribute. This
> way both Concrete-Model1 and 2 can use the same as, and it's
> genericBuild that's then forced to use two different 'as' attributes
> for them to be able to distinguish them.
>
> It's analogs to Java's inheritance, where a derived class can only
> refer explicitly to its direct parent's methods, and not any of its
> ancestors (like in C++). In other words, you can only bypass the
> normal virtual dispatch of method if it's a method of your parent.
>
> There's no reason for genericBuild to directly reference
> Abstract-Module. Abstract-Module basically became "part-of"
> Concret-Module1 and 2, and is invisible to genericBuild, unless
> genericBuild also directly import/includes it.
>
> Failing to do this, you couldn't safely refactor Concrete-Module1 and
> 2, without possibly breaking genericBuild.


I think this is a good idea, even if i have no idea of how to implement it.

Maybe we can improve "target visibility" (something close to private /
public).
Project help should be able to display "public" target of a given submodule.




>
>
> Ah, it looks to me that I'm again failing to get my view across. Since
> I'm no longer actively using Ant like I used to, I'll take a step back
> and stop arguing the above points, which are probably incompatible
> with the (simplistic?) way Ant deals with import and target addressing
> (by simple prefixing).

I'm really interested by your point of view :), maybe because you seems to
be on of those who tries to "faire avancer le schmilblick" comme on dis chez
nous ;)


>   - <use> is like a "Rich" <import> that support namespace and that allow
> >   you to import many time the same build script with different namespace.
>
> And I thought use was like an include ;) i.e. less than import, while
> it's actually more. --DD

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message