On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote: > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
>> Your proposal uses a <local> task that sets up a local scope for a >> named property until the enclosing target/sequential finishes. >> Jose Alberto suggested to use a <local> TaskContainer instead, >> something like > > I think that this looks clumsy. possible - I'm not afraid of looking clumsy 8-) This is IMHO a case where verbosity is a win. > (note as well that local-property is not a valid name, Why not? Nothing's going to stop my from taskdeffing that name and <local> is a TaskContainer. Anyway, I'm in no way attached to any name, I would even be fine with <let> as the name of the container, but I'm afraid that not too many users would recognize this. >> (2) Shadowing of properties >> >> I think they shouldn't be allowed to override any outer scope >> properties at all. > > I think that this will reduce their usefullness a lot. Maybe. It would be enough to isolate macrodef invocations from each other, though. Allowing them to override "plain" properties opens up the "properties are immutable" rule and makes it a "properties are immutable unless overridden in a <local>". This even stronger asking for a TaskContainer IMHO. What is your usecase for overriding properties? > The idea of not overridding user properties comes from the <ant> > family behaviour, Not only. Even setProperty will not override a use property. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
