On Wed, Apr 20, 2005 at 08:45:02PM +0100, Scott McWhirter wrote:
: Hi,
:
: I've not been keeping very up to date in recent times of how this stuff
: is working. I've been noticing the use of these variables within pugs
: and have a slight suggestion.
:
: Currently there is rather limited abstraction with these items (as far
: as I am aware) and while they are usable and comparatively similar to
: the perl5 ways of doing things, I see a benefit in changing how these
: work.
There has been some discussion of this in the past. Certainly the
mechanisms are there do whatever aliasing/wrapping/delegation needs doing.
: I would like to suggest changing the $?OS, etc variables to being
: attributes of a class which always have a singleton object within the
: outer-most scope of a process. ie:
:
: class GLOBAL {
: has $.PID;
: has $.OS;
: has $.UID;
: ... # etc
: }
:
: I believe though, that keeping things the way people expect is also
: important, so keeping $?OS, etc. about is still important. To accomodate
: this I suggest exporting these variables from the GLOBAL class as Proxy
: objects which in turn use the accessors on the GLOBAL singleton object.
Well, there are several global namespaces already, so you'll have to
differentiate more than that. We already distinguish $?FOO (compile-time
global) from ?*FOO (run-time global), plus $=FOO is the pod namespace.
There may be others, and that doesn't count splitting things out by
things that are global to the thread/process/OStype/OSinstance/whatever.
Lumping these into one GLOBAL object is to make most of the same mistake
under a different name.
: Why would this be useful? Why should anyone care? Well, a real world
: example would be if I wished to find out through a large codebase to
: locate all the areas within the codebase that are calling $?OS. To do
: this, I would simply override the $.OS accessor in the GLOBAL class to
: provide logging.
:
: Although I'm not entirely sure how this would fit into the usage of
: compile-time vs. run-time, I would believe that this abstracted approach
: would be beneficial wherever it was used. Hopefully that made sense
It's a good idea. We just haven't finished designing that part of it.
Anyone who wants to help with that part of the design is welcome to
participate--it's not the crown jewels, and as you say the important
ones end up getting aliased into global namespace anyway. We're taking
the same approach with redesigning the function call space (aka S29).
Larry
