$?OS globals, etc.

[Scott McWhirter]

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-

Re: $?OS globals, etc.

[Larry Wall]

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

Re: $?OS globals, etc.

[Larry Wall]

On Wed, Apr 20, 2005 at 08:45:02PM +0100, Scott McWhirter wrote:
: 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