On Tuesday, April 30, 2002, at 09:18 , Jackson, Harry wrote:
> Is the following more suitable or is it bollocks as well. keeping timothy's kind and gentle rebuke in mind..... { my complements timothy!!! } There are two sets of competing concerns: a) get the code to work b) have code that can be maintained { and when the money is right, they may even pay you to write 'safe' code.... but never hold your breath on it until the law suit backs them up against the wall on needing to have 'security' right up there with 'quality' ... } That the code runs under strict and with warning means that it clearly passed a more stringent set of issues on (a) than code that is 'in production' - the problem is with 'b' - and hence my core concern with my $TRY = "world"; my %TRY; note that at a quick glance $TRY{$h}=3; it is possible to 'obsese' on the '$TRY' part... So as a general rule of thumb try to lay out the variables that you plan to use in a way that is less likely to leave any shadow of a doubt as to what is really going on. As chas' recent kvetchings noted - there comes that time, at 'oh dark squat' when you are typing and not thinking.... Many of us 'old guys' were so excited when compilers were able to use both upper and lower case letters, as that meant that we could extend the range of our variables and function names to things like $DamnYankee = getCarpetBagger(@arglist); #honest it is one word... rather than all in upper case. with the inclusion of "_" in the token list of parsables that could be used we can "expand" that line to what is argued to be a more readable $Damn_Yankee = get_Carpet_Bagger(@arglist); Your Mileage may vary - but this clearly easier to get an idea about than say $a = cb(@b); So since one has a wealth of lexical tokens to create - why not do the decent thing and avoid putting scalars and list variables so close together in the name space. Granted at times I tend to do sillies on gp: my %tmpHash = (); so that when I stumble across it later on as $tmpHash{$key} = $val ; I have the awareness that I am putting that val at that key in that hash..... not that I am trying to do some triple expansion value eval that will allow me the hyperAreobesque into a much happier place... { that at times there are need for things like @{<stuffhere>} should be left for when you really need to be doing that... } yes, I know that I have production code with embedded jokes: @list_shrugged.... but at least at a glance I know that I have a list... So the first trick is to protect the 'name space' - NOT for the compiler - Pork The Compiler - but so that you are not going to get lost in your own code - I am still in the debate between the 'import' v. 'direct call' approach: use Wetware::DTK; ... my @cool_list_of_Things = &Wetware::DTK::getCool(@list_shrugged); as opposed to use Wetware::DTK qw/:cool :weird/; ... my @cool_list_of_Things = getCool(@list_shrugged); But that way leads us into where i expect a percentage of folks will wind up - they did enough perl that they wind up with enough basic 'site local' functions that having a perl module is a rational extension.... So the naming the variables and functions games should start simple and stay simple as long as you can ... to recycle the old cobol joke: "If you mother can read your code and understand it.... then there is half a chance management will too...." And more importantly that YOU will at that odd hour. Once one is in the habit of thinking about naming variables appropriately - then one starts also natively thinking in terms of what sort of 'data structures' come 'native' to the coding language that one is in. In /bin/sh - there is really no such thing as a list - and worse yet one has no such critter as a hash so you wind up doing things like LONGHASH="key:val key1:val1 key2:val2" so that one can do the for entry in $LONGHASH do # suck out the key val pairs here eval `echo $entry | awk '{ split($0,spot,":"); print "KEY="spot[1] , "VAL="spot[2] }'` echo "Have $KEY and $VAL" done { and people sed that things were so awkward in shell... } So if one finds that the data starts laying out that way, and one always did the above in /bin/sh - why do it in perl? $LONGHASH = "key:val key1:val1 key2:val2"; why not simply DO the %long_hash = ( key => 'val', ..... ); and go with the ugly duckling while ( my ($key, $val) = each %long_hash ) { print "Have $key and $val\n"; # and did with them as I will.... } All of which then leads to the: Why try to globellate: print @array$a[$b]; when one should look at the data - and decide if one is trying to be a coder - or is one trying to find a way to get something else to do the data analysis and matching of the data to the data structure for you? Simply so that one can funk around have have funky expansions that look almost like World0[$a] .... IF the compiler actually generated up 'strings' to manipulate - rather than FUNKY 'bit streams'.... The Text IS Your Side of the Line. The 'bit stream foo' you should leave to the compiler. At which point when you get to: print ${"array$a"}[$b] ."\n" you will notice that it required an inline 'interpolation' of the double quoted string to find a reference to an array. and you are of course out and away into the land of complete WakkaDoodelEdge.... please READ Jeff's Comments: > > Mark-Jason Dominus has an article about why using a variable as a name for > a variable is a bad idea. Symbolic references are a left-over artifact > from The Land Before Perl 5. They are wizardry, and should be avoided > 99.9% of the time. There's about ONE place where you should use them, and > even then, you probably don't need to. > > http://perl.plover.com/varvarname.html please DO read mjd's article. IF you still feel an exception emotional need to work in that space - feel free to find a planet that matches the colour of the sky in your world..... and do send postcards.... 8-) ciao drieux --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]