On Tue, 2005-04-26 at 11:39 +0100, Nigel Swinson wrote:
Now I'm nervous about an extension which exposes some const and some non
const variables in a namespace.... :o/ I guess we could expose two
namespaces which goes against the SHOULD but then you didn't say MUST so
maybe that's ok...
You didn't comment on the above, so you prefer the idea that if
extensions need to expose readonly/writable varaibles, that they
expose two namespaces?
no.
I'd really rather they just expose the one. The extension can then
detail which if any varaibles in the namespace are writable.
exactly. I don't think the wording restricts this?
The "set" action stores the specified value in the variable
identified by name. The name MUST be a constant string and conform
+ to the syntax of variable-name. Numbered variables can not be set.
+ A namespace can not be used unless an extension explicitly allows
its
+ use in "set". An invalid name MUST be detected as a syntax error.
I'm wondering if saying that "Numbered variables can not be set" is made
redundant by your comments that an extension should state whether its
namespace is modifiable with the set action. Certainly it feels quite
restrictive to have it said in both places.
there's no namespace for numbered variables, so I don't think it is
redundant.
You are saying that an extension may expose a namespace, and that
namespace may itself contain numbered variables can't it?
no, my current copy includes this definition:
A "numbered variable" has a name consisting only of decimal digits
and has no namespace component.
the term "numbered variable" is restricted to the magic match variables.
perhaps I should replace the term with "match variable" -- might be less
confusing?
So that extension will also detail if it's variables are writable.
Hence why can't a new extension expose a namespace containing writable
numbered variables?
they can expose writable variables with all-digit name components.
--
Kjetil T.