On Thursday, June 20, 2002, at 09:01 , Jeff 'japhy' Pinyan wrote:
> [NOTE: this is a reply to a SATIRE, so don't wig out]
what? you mean it's not a good basis for a 4/1 RFC standard???
> On Jun 20, drieux said:
>
>> my %globals; # where we hide all our globals
>> # so we can access them as $globals{var1}
>
> Why not "hide" them in %main:: instead?
Well I had thought about that - but felt it would be
more obvious that one were using something out of the
Global declaration section - besides by declaring only
the %global hash itself at the start of the process -
and having a formalized standard - one could constantly
extend the list of globals to be used automatically - in a
way that would allow global variable locking and self definition
structuring.
Syntacically one could have
my $global_variable_var1 =
%{$global{var1_info}}{get_method}($global{var1});
and always know that one had used the right Get Method...
Clearly a more robust solution than say
my $first_argument_from_command_line = $ARGV[0];
which doesn't generalize too quickly - note below about the
whole "_info" associative array to be defined for all global variables.
>> then remember that keys into this hash should be identified
>> by a _[ahs][r] suffix.
After sending it I noticed that I had not called out
the whole
$global{<var_assertion>_info}
portion of the process that would be the 'information'
hash about the variable_assertion - hence defining at
least
get_method => what sub gets this variable
set_method => what sub sets this variable
bug_number => what defect tracking report was the excuse for this
global
bug_owner => who is the owner of this global
new_bug_numbers => the list of new defect tracking report numbers in
the system because of this global variable.
rand_method => reference to random method for misUsing this global
last_access_time => time this global was last accessed
last_caller => function that last used this variable
known_side_effects => list of reported side effects caused by this
global that are distinct from
using placebo code
in double blind testing.
Stock_Ticker => which was the hot NYSE/NASDAQ symbol being tracked when
we opted to create this - must be set
if
bug_number is undef, or while
new_bug_number is
less than the Strike Price of your
options
All of which leads to a much more self documenting approach to
global variable declaration process than the more pedestrian
use vars qw/..../;
and requiring that the variables be named after what they do,
vice merely var1, var2, var3....
> Why not use a $, @, %, &, or * prefix instead?
true, one might try that - but the problem is getting
them into the key in a way that makes sure that they
are not misinterpreted as perl information...
> Why not use Perl as it was given you? ;)
a) Not self documenting enough.....
b) Too Much Caffinee????
c) The Voices in my Head Made Me Do It?
d) A BRILLIANT FLASH OF LIGHT - that one
could actually articulate a 'standard' for using
a whole bunch of globals in a way that would be
reasonably extensible, self documenting, and less
likely to allow side effects than the usual perl bad habits
of badly named spammed global variables.
e) BrainWaveSuckingSpaceAliens
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
