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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
