global, globals(), _global ?

[Alex Martelli]

robert <no-spam at no-spam-no-spam.com> wrote:
   ...
> > Ruby does ($ means global), but, what other languages?  Perl, C, C++,
> > Java (taking a class's statics as Java's equivalent of other languages'
   ...
> I though first of Ruby.
> 
> Good C++ code uses  m_ , g_  for members, globals, ...  e.g. the 

_Some_ C++ code uses such guidelines, but I think you're assuming way
too much by implying that (all) good C++ code does that.

For example, the Google style guide (and I assure you we have a *LOT* of
C++ code, and it *IS* pretty good indeed) uses a different convention
(not a prefix) for instance variables, and no 'stropping' distinction
between locals and globals (even though I'm more into the Python side of
things, than the C++ side, I do work regularly at Google in both
languages, I passed my "readability certification" for C++ as well as
Python, proving I know and apply the Google style rules very well, and
I'm very aware of the long exhaustive debates on which each language's
style guide is based and by which it keeps getting tweaked when needed).

Remember, for example, that part of what defines "good" C++ style (in a
firm developing lots of software in both C++ and Python) is the ease of
using SWIG (or other tool of choice, but Google prefers SWIG) to wrap
the C++ code so Python can use it too.

Anyway, guess we should move this particular discussion to a C++ forum,
and similarly for the Java one, the Perl one, and so forth. Let's leave
it at this: Ruby's the only language that mandates stropping for globals
(in any language you may choose to adopt such _conventions_, just like
you could choose, e.g., Hungarian notation -- silly, but possible;-).

> Microsoft MFC code ( you have to declare the vars anyway - and it is 

I've worked FAR too much with Microsoft's MFC (back when I was a Windows
and C++ guru, in the '90s) to accept their being claimed as an example
of "good C++ code" as anything but not-thinly-veiled sarcasm!

MS itself doesn't like the MFC any more, indeed they first tried
replacing it with the WTL before (essentially) giving up on C++ (the
main designer of C# was the same guy who earlier designed WTL;-) and
opensourcing WTL (IMHO still the best way to do Windows GUI in C++, if
you're condemned to such a worse-than-death task;-).

> compiler checked unlike in dict-languages ), :: for global namespace.

"Per-module-global", though, is the unnamed namespace (used to be
'static', but that's deprecated at global scope nowadays)

> I think its good to leave the default global binding (that is probably
> whats Guido doesn't want to give up for good reason)

Then, on the principle that there should be preferably only one obvious
way to do something, we'll never have an _global object as you propose
(even by any other and much better name;-), because it systematically
produces TWO equally obvious or unobvious way to access globals.

> Yet frames could expose their top-dict anyway as a virtual inspection
> object (__l/__l_<funcname> or  __f_stack[-2]) . Or at least writing to
> locals() could be defined as writing to the top-frame-locals. 
> Sub-Frames could write free there (its a rare & conscious task anyway)
> and the Frame itself could read either way.

Not sure I entirely understand what you're proposing, but locals access
must remain compile-time-optimized for crucial practical reasons, so
"writing to locals()" just will not work right.

> Another ugly possibilties maybe by enriching variable assignment.
> 
> Maybe '=' can be enriched like   .= ..= :=  =: ::= =:: xxx-set ... etc.
> in order to be an expression with result value and to allow to writing
> to certain namspaces.

Ugly enough that Guido has never wanted to entertain such possibilities
each of the many, many times they've been proposed on python-dev over
the years.  python-dev is archived and easily searchable -- maybe you
can research the last few years of discussion there, assuming you're at
all interested in seeing your proposals implemented in Python.


Alex