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 ...
Yeah, fair enough. We need to talk about your iterator stuff in general, though it's applicable here. I think it's time to add some iterator support to the vtables, since we need them in a bunch of places. (I was trying to keep them out of the core just to cut down on the complexity we need to manage, but I think we're past the point where that's feasable)
> 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?
Sorry, what I meant is that there isn't just one environment PMC that's shared across all interpreters. We certainly can share PMCs across interpreters, that's pretty much required.
>>- defined_keyed, exists_keyed delegate (after possibly) filling the hashto 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?
It's more than that. On windows and VMS, the environment is a bit more complex than Unix's. With Windows you've two levels of environment (user and everyone) and with VMS you've got multiple levels, multiple tables at each level, and each entry in the environment may actually be an array of entries rather than a single entry. (akin to the ; as separator thing that Unix uses, only built-in)
> I think ultimately we may want to have an interpreter-specific envPMC 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.
Potentially, yes. We still ought not cache, since otherwise process environment changes made outside the interpreter won't register with us, which would be bad.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
