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


-- -Scott McWhirter- | -kungfuftr-

Reply via email to