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. 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.

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

thanks,

--
-Scott McWhirter- | -kungfuftr-

: 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

: 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.

Oh, I was also going to point out that a simple .wrap is probably
what you want there, rather than screwing around with overrides that
depend on clobbering the class or on type changes getting propagated
to existing variables.

Of course, a .wrap could be construed as clobbering the class, but if
you don't want to change the underlying functionality, it's a lot
cleaner than replacing the method in question.

Larry