Food Fight

[Phil Davis]

Hi Dennis,

Dennis Brown wrote:
> Dar,
> 
> Thank you for standing up for the rights (in a good natured way) of  
> those who think it's overkill to have all these structured names in a  
> conversational language with handlers that are usually only a few  lines 
> long.  Why mar the elegance of a understandable name with  cryptic 
> unpronounceable prefix letters all over the place?  It's not  as if I 
> wouldn't be able to instantly recognize ten years later what  the local 
> variable named partNumber in my 20 line script was for, or  even that it 
> was a local.  I can see the rationale for this structure  when writing 
> many huge (multi-page) handlers where you might actually  forget what 
> the names were for by the end --but most of us don't do  that.  I think 
> it is usually better to break things up into byte  sized pieces by 
> defining small handlers and functions that  essentially extend the 
> language in problem specific ways.


But as I understand it, it's less about whether it helps me remember and 
more about assuring that my product 'plays nice' with other products. 
Using these conventions prevents me from creating a global name in my 
libraries/products which simultaneously (1) spans the entire Rev session 
namespace [as all globals do], and (2) is already used in someone else's 
product/library, which also spans the entire namespace. Obviously that 
could cause severe problems in both products that accidentally share 
global names.

I suppose a compromise would be to say the conventions are a 'must' when 
creating global names, and a 'maybe' when creating other container 
names? That way you get protection without losing all sense of personal 
freedom.

Phil Davis