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