www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - explicit syntax for accessing class members and globals

reply Serg Kovrov <kovrov no.spam> writes:
Hello D-people,

It is strange I didn't encounter debates regarding subject so far. That 
I mean is a way to distinct class members and globals from local 
identifiers. For example forcing to use 'this' to access member data and 
methods.

Then I first saw this approach in PHP (after C++ background), I was 
thinking that it is a stupidest idea - to type (and see) 'this->' 
allover again. But in time I get used to it and do really appreciate it. 
You see, benefits for a little more typing is code, much easier to 
follow. I find exploring foreign C/C++/D code is a bit pain because I 
always need to lookup and track identifiers - is it member or local or 
perhaps global, or even worse it might be hidden by local member... I 
bet you know the feeling.

Personally I avoid those pitfalls using (my own, sorry) naming 
contentions. So I have no problems with my own code, but what is my code 
compared to whole world =)

Good IDE able to highlight such information, say in tooltip, could help 
a lot. To bad we do not have one =(  And not always even if exist, good 
IDE available. For example looking at code on web page or paper.

It's a bit late for proposal, as such change will break too much 
existing code (although, fixing this would be not so hard for code 
maintainers), but I'd like to know your opinions on that matter.

thanks
-- 
serg.
Sep 04 2006
parent reply Sean Kelly <sean f4.ca> writes:
Serg Kovrov wrote:

 Hello D-people,
 
 It is strange I didn't encounter debates regarding subject so far. That 
 I mean is a way to distinct class members and globals from local 
 identifiers. For example forcing to use 'this' to access member data and 
 methods.
 
 Then I first saw this approach in PHP (after C++ background), I was 
 thinking that it is a stupidest idea - to type (and see) 'this->' 
 allover again. But in time I get used to it and do really appreciate it. 


It's obviously not enforced by the compiler, but I prefer a naming 
convention to distinguish class member data from other data.  Prefixing 
"this." to everything is relatively verbose, and the compiler still 
won't catch all bugs if you have a local variable with the same name as 
a class member variable (though I believe this is actually a "shadowing" 
error now).  In any case, the convention I use is:

class C
{
     int        m_val1;  // "m_" prefix for class members
     static int sm_val2; // "sm_" prefix for static members
}


Sean
Sep 05 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Tue, 05 Sep 2006 13:06:01 -0700, Sean Kelly <sean 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.
Sep 06 2006
parent reply Serg Kovrov <kovrov no.spam> writes:
* Steve Horne:

 On Tue, 05 Sep 2006 13:06:01 -0700, Sean Kelly <sean 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.
Sep 06 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Wed, 06 Sep 2006 14:19:32 +0300, Serg Kovrov <kovrov no.spam>
wrote:


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.


Readability is always, in the end, the responsibility of the
programmer. There are always more ways to write unreadable code than
to write readable code.

Despite all the style guides and the efforts to impose readability by
authoritarian standards, there is no simple set of rules for what is
or is not readable. Every style guide ever written can be ridiculed by
simply finding the right example and working to rule.

Readability is inherently subjective, by which I mean context
sensitive much more than I mean a matter of personal judgement. Many
different factors affect the readability of any single piece of code,
and some of those factors will always be in conflict.

For instance, a more explicit style can certainly make code clearer.
But it can also make code more cluttered, obscuring what is important
by burying it under tonnes of trivial details. This is why high level
languages were invented in the first place.

And so programming language designers have to make choices - what
should be explicit and what should be implicit, what should be
enforced and what should not. Sometimes there are overwhelming reasons
for going one way or the other. And sometimes, it really comes down to
subjectivity, in the sense of personal taste.

That's why I'm sticking to my guns. There's nothing wrong with your
opinion, and it works well enough in those languages where it is used,
but it isn't any kind of absolute. And I want my existing code to
still work tomorrow, whatever language it is written in.

-- 
Remove 'wants' and 'nospam' from e-mail.
Sep 06 2006