----- Original Message -----
From: "Magesh Umasankar" <[EMAIL PROTECTED]>
>
> -1
Lame. Sorry.... its just such a globally beneficial thing but heck, what do
I know.
> Though <property environment=.../> has set
> a precursor of letting in a prefix, providing
> prefix attribute to <property file=... prefix=.../>
> is a very short-sighted implementation and
> is not generic, IMHO.
It isn't designed to be generic. Its designed to prevent name clashes, that
is what environment="env" does. And that is what a prefix="..." would do.
That is all.
> If we introduce the attribute prefix today,
> I would want to have the attribute suffix
> tomorrow, the ability to replace keys or values
> with some other key strings on the fly, day after
> tomorrow.
You're making up extremely contrived scenarios that have never been
requested. If you want to morph the actual property file elsewhere that is
a different story and no doubt way out of scope for <property>.
> Right now, if a property file
> has two identical keys with different values,
> only the second key will be loaded. Not that I would,
> but if I want to be able to differentiate
> identical keys by attaching a .1, .2, .3 suffix
> at runtime, I can't and I would need to morph
> the property file into a new property file using
> some other tasks (I don't even know if it is
> possible, right now)... Someday, I would
> want to load only those properties in a
> properties file that contain the key string
> "Init" or something like that.
Again, a really really contrived scenario, of which <property> is out of
scope for and a very good use-case would have to be made for me to consider
touching something like that.
> I have already proposed an alternative way to
> implement this feature - that of transforming
> keys & values present in a property file before
> loading them in as Ant properties.
Thats just a way too "complex" syntax and usage, IMHO.
When you're a filter reader everything looks like a nail.
Sorry Magesh, no offense.... I'm just perplexed why this particular issue
turned into a -1 and a far more complex and involved thing.
Anyway, saved me a bit of coding! :)
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
