explicit syntax for accessing class members and globals

[Serg Kovrov]

* Steve Horne:
> On Tue, 05 Sep 2006 13:06:01 -0700, Sean Kelly <sean at f4.ca> wrote:
> 
>> It's obviously not enforced by the compiler, but I prefer a naming 
>> convention
> 
> Agreed. But I'm not so sure about...
> 
>>     static int sm_val2; // "sm_" prefix for static members
> 
> To me, the fact that it is a member is sufficient. Context tells me
> whether it's static, since my classnames have a 'c_' prefix.
> 
> l_Varname.m_Membername
>   *Could* be a static, but much more likely an instance member.
> 
> c_Classname.m_Membername
>   Must be a static member.
> 
> Actually, I'm amazed how quick and easy it has been replacing all the
> '::' and '->' operators with a simple dot. I'm being spoiled. I may
> have serious tantrums when I have to go back to C++ ;-)
> 
> Getting back to the point, I'm not particularly bothered by (for
> instance) the explicit 'self' in Python, but I don't see it as an
> advantage either. There are no major costs or benefits either way in
> my opinion.
> 
> The important thing is that a language shouldn't make breaking changes
> for the fun of it.
> 

Of course, programmer who care could write:

ClassName
methodName(param_name)
StaticMethodName(param_name)
m_classMemberName or _classMemberName
sm_StaticMemberName or _StaticMemberName
locaVarName
package.FunctionName() or PKG.FunctionName() //shorter alias for package

If he cares about readability of his code by others it is perfectly 
fine. But it's a big 'if'.

You can imagine what mess could be if he doesn't...

But consider 'careless' code with forced 'scope prefixes' (sorry, i'm 
not sure how to call it):

this.do(param)
this.bar
classname.donow(param)
classname.foo
mywar
.thevar                //dot is global id
package.doit()         //forced fqn or alias

If you understand from this example (and i'm sure you are) what scope 
this identifiers belong to, you could see how this restrictions make 
much harder to foil a reader even on purpose.

--
serg.