Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 10:09 AM +0200 7/11/03, Leopold Toetsch wrote: >> > pmclass Env extends default { >> >>What do you think of: >>- Env extends PerlHash
> Thought about it, but I couldn't think of a reason why. %ENV{'something'), keys(%ENV), iterating over %ENV ... > I'd considered that, but I don't think it's necessarily a great idea, > as it introduces a layer of caching that can get defeated by threads, > since we're not sharing a single PMC across all the threads. (Though > we probably ought to) What about ParrotIO PMCs? You are sure, we don't share PMCs? >>- defined_keyed, exists_keyed delegate (after possibly) filling the hash >> to SUPER(). > Possibly, yeah, I can see that. > I'm also considering means to override the way this behaves since in > an embedded context direct get/set/unset will be potentially > overridden, and then there are platform-specific overrides that folks > may want. (For VMS and Windows, for example) The platform specific part is already hidden by using Parrot_*env() functions. Or do you think of an intermediate layer between platform and Env PMC? > I think ultimately we may want to have an interpreter-specific env > PMC that is, by default, an Env PMC, but can be overridden at > creation time, and we just disallow "new Px, .Env" calls, or > something of that sort. I think one Env PMC ought to be enough. And that one may have e.g. an Iterator ettached, which simplest is done by deriving it from an hash like PMC. leo