> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > On Fri, 4 Jun 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote: > > > This allows to bypass the target override, and thus bypass whatever > > the overridden target does. > > Right. But I already can bypass it if the target is > overridden since I get the aliased name then. If this type > of bypassing is wrong, we shouldn't allow it in any way. >
This is one of my pifs with the current import, a battle I think I lost. Or maybe I won (I cannot remember which side I was :-( ) As in any inheritance based language, what you need is two things: 1) Been able to override to change behaviour. 2) Been able, from the overriding module (project) to call the original behaviour that you overrode(sp?). (1) we acomplish, but (2) I do not think we did right. Here what we needed was having "super" (or in our case since we have multiple inheritance) to be able to refer to several supers. But we did not do that, we do not give access just to the previous definitions (super) we kind of gave access to all definitions which I am sure will create spaguetti builds in the future. I remember someone pointing out that our big mistake on <import/> was that we use the name of the project being imported and not a name local to the importing build as the way to refer to "super", this in escence breaks visibility rules. So if we have: imported.xml: <project name="foo"> <target name="baz"/> </project> build.xml: <project name="here"> <import file="imported.xml" id="there"/> <target name="baz" depends="foo.baz, there.baz"/> </project> The depends list shows the issue, the first target "foo.baz" requires the writer of build.xml to know not only the name of the imported file but also details about its content (beside the contract of providing a "baz" target. The second target "there.baz" does not require build.xml to know about the internals of imported.xml. More over, there is no way to talk about things further imported, since the only thing you have is your local ids (or that is the idea). Now this is not easy, since requires visibility rules much more dinamic than the syntactic rewriting we have today. > I don't have a real world use-case, granted, my major reason > is consistency - I want to be able to write depends="foo.bar" > and not care whether it has been overridden or not. Not sure if this is just adding more logs into the fire (as we say in spanish) Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
