drieux, et al --

...and then drieux said...
% 
% On Saturday, July 13, 2002, at 07:11 , David T-G wrote:
% 
% In the main I like where this is generally going.

Yay :-)


% 
% A part of my argument with myself today has been about
% 
%       which is better? all 'teaching code' should be 'virgin clean'???
%       or should we show the actual process by which ideas mutate from
%       a quick sketch to a 'completed' piece?

I like the latter to a degree; a mix where we show just a couple of
first ideas with their problems and then very quickly get to Really Good
code would do well.


% 
% Far too many times the 'way we learned' a coding language has little
% to do with how we present the coding language.

Heh :-)


% 
% tell me what you think of
% 
%       http://www.wetware.com/drieux/pbl/perlTrick/CBO/jobBot/
% 
% where I am trying to do some of what I think you are asking about
% in terms of 'if you do foo....'

Yeah, I see.  I like it, though I'll have to read in more depth when I
have time.


% 
% [..]
% >I think this could be expanded to show use of "local" or "our" vars for
% >those who *want* to expose $z but must still see the dangers in not using
% >"my".  Just a thought.
% 
% This has me concerned - it could be the way that the phrase is turned.

Certainly it could be :-)


% 
% if one starts with the simple mandate of
% 
%       though shalt use '-w' and 'use strict'
% 
% then the choices are limited

Fair enough...


% 
%       any variable that one would 'local' with,
%       needed to have been declared with

Right; AIUI 'local' allows a called subroutine to see a 'my' var when it
would otherwise not descend into the new scope.

I *think* I understand this.

  - 'my' defines a var for only this block and does not export to
    subroutines

  - 'our' defines a var that is basically a global

  - 'local' defines a var that is like a 'my' but is visible to children
    of the scope so that called subroutines can see it

Of course, if I don't then some of this discussion may make a lot more
sense in its nonsense :-)


% 
%       my or our
% 
% remember that 'our' is a 5.6-ism if I recall correctly.

Ah.  Didn't know that.


% 
% So i am not too sure i 'grok' your assertion
% 
%       'see the dangers in not using "my"'
% 
% as a contrast to 'our' or 'local'.

Well, if you don't use 'my' then you're definitely in trouble.  If you do
use 'my', though, you can't see the variable in a subroutine.  When
you're recursing and don't want to step on $x again that's good, but when
you're calling another routine and want to see $z then you'll be stuck.


% 
% >This leads me to ruminating on global variables in general.  Things like
% >config vars -- %ENV
% 
% these are essentially out of your control 'at start up' - if
% by 'config' you mean the set that are 'built in' and accessible
% with 'use Config'???

No, not 'use Config'.  I mean the path or other passed-in vars (mebbe
web page field vars) but also config stuff like

  $gzip='.gz'
  $verbose='on'
  $addr='[EMAIL PROTECTED]'
  
as default settings for the code you're writing (maybe you'll turn
$verbose off with a command-line flag, but you want it on by default).
For that matter, what about a $verbose or $debug var that you use all
over the place to see if you should print out extra stuff?


% 
% >or a switch that says to do this one way or another
% >or the like -- seem well suited to being global.
% 
% the problem is that 'globals are' - there are bunches of
% them that are defined all over the place - and one therefore
% wants to 'manage' the problem as best as one can.

Yeah.


% 
% > Perhaps if declared with an "our" at the main scope level...
% 
% one advantage of this is that you can establish a reasonable
% habit of putting them where you know that you can find them...

I like to do that, though I do admit that tight scoping can be good.


% 
% The alternative habit of 'declare them where you need them' - has
% the reverse 'bite you' problem.
% 
%       while($still_do_me) {
%               .....
%               my @accumulator ;
...
%       cope_with_them($_)
%               for (@accumulator);
...

Exactly.


% 
% >Can one safely and sanely make
% >the argument "thou shalt NEVER have an unadorned variable" or is that
% >just pushing a little too hard?
% 
% well.... think about it, the moment that you mandate
% 'use strict' and '-w' - the code will run, but it
% will whine without 'adorning' your variables as to
% whom they belong to....

True.  Perhaps I should have said "non-'my'", since the discussion is
really about the times when you WANT globals.


% 
% ciao
% drieux


Thanks & HAND

:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

Attachment: msg27614/pgp00000.pgp
Description: PGP signature

Reply via email to