Revised RFC on range design for D2

Chris R. Miller lordsauronthegreat at gmail.com
Sun Sep 28 19:50:19 PDT 2008


Andrei Alexandrescu wrote:
> Chris R. Miller wrote:
>> Improper use of properties make code that looks ambiguous.  Is that a 
>> public member or a method?
> 
> Under what circumstances is that distinction important?

My lack of example situations is offset by my fear of one day finding 
one as a problem.

>> It reduces codebase coherency
> 
> How? Why?

In Java, if something was called like a function with the () and 
everything, you could be pretty dang sure it's a method.  In D, if it 
doesn't have a () when you see it, it could still be a method called as 
a property.  The only way to find out is to look it up, which can be 
tedious and boring.  If you don't look it up, you may never know, which 
reduces the coherency of the code.

>> , which is normally not a huge problem except when new programmers are 
>> reading through the code to see how it works.
> 
> Why do they need to know whether it's a computed or a state value?

I prefer to know what I'm doing when using an API - or any other code, 
for that matter.  I think the more information you have about a system, 
the better able you are to make use of it.  A method call indicates a 
potential for additional machinery behind the scenes, which can be 
useful information when deciding how to craft an algorithm that makes 
use of other code.

>> If someone mistook that method call via property as a member, then 
>> they might use it as such in code they write.  Because it's actually a 
>> method, it has the potential to rope in serious amounts of processor 
>> work.
> 
> That is the complexity issue that was discussed a while ago in the 
> digitalmars.d group. I agree that certain interfaces should come with a 
> complexity guarantee. But the line is definitely not drawn at 
> member/computed value. Besides public members are bad style to start 
> with, so essentially the argument is that everybody must litter their 
> code with (). Why? Because there is the implied assumption that what 
> doesn't have the () is a member variable access. I am challenging that 
> assumption.

We could just do as Objective-C and use that strange typid foo = 
[NSObject toString]; syntax, which would negate the need for the whole 
discussion.  ;-)

>> It's the same reason you don't want to overload simple operators in 
>> C++ with potentially large algorithms, since it creates an illusion 
>> that the operator is really a simple operation when in fact it could 
>> be quite tedious.
> 
> I agree. That is what the STL does.

STL is... strange, and I have not yet been well versed in it.  The likes 
of superdan has convinced me that there is something of substance in it, 
though until I can really find some time to sink my teeth into it, I can 
have but no comment.

>> This is - of course - a matter of practice with C++, and isn't a 
>> language requirement, but it does illustrate that it's something to be 
>> conscious of.  Similarly, you wouldn't want to load up a D invariant 
>> with a lot of hard processor work, since that would incur a lot of 
>> overhead following each public function call.  There's nothing 
>> explicitly wrong about doing it, it's just bad practice (according to 
>> some).
>>
>> I hope that was coherent.  I believe I read about it in /Code 
>> Complete/, if you want a source.
> 
> I don't have the latest, so a quote would be helpful.

Actually I think it was from "Game Coding Complete" (Mike McShaffery, 
2003).  I seem to remember it being in proximity to another rant about 
how polydimensional vector addition using overloaded operators is a Bad 
Thing (TM) because junior programmers will do it left and right thinking 
"Eh, it's an operator, therefore fast!" when in fact is was a hugely 
expensive operation that should be avoided to speed up things.

My brain leaks, I may never fully remember where it came from until I 
find that book again (somewhere in my room, though not sure where).


More information about the Digitalmars-d-announce mailing list