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
