Revised RFC on range design for D2

[Andrei Alexandrescu]

Chris R. Miller wrote:
> Leandro Lucarella wrote:
>> Chris R. Miller, el 28 de septiembre a las 19:50 me escribiste:
>>>>> 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.
>>
>> In Java you have the exact same problem. Since it doesn't support
>> properties, and people don't want to chage thousands of LOC if they need
>> to change a simple member variable to a function, they use functions just
>> in case. So when you look at a function, for example, getSomething() you
>> still wonder: is this just a simple return something;? Or is *really*
>> a function?
>>
>> The problem is the same, you just have to use uglier syntax =)
> 
> In Java for some reason the "Industry Standard" was that using 
> non-constant public members was a Bad Thing (TM), and that getters and 
> setters were the only acceptable thing.  For most things this was more 
> or less just an annoying function set that looked like this:
> 
> class Foo {
>     private String bar;
>     public void setBar(String bar){
>         this.bar=bar;
>     }
>     public String getBar(){
>         return this.bar;
>     }
> }
> 
> Other times (rare, I never personally needed it) they were important to 
> allow input checking (what we'd do like this:
> 
> void setBar(char[] bar)
>  in {
>     assert(bar.length>=3);
>  } body {
>     this.bar=bar;
>  }
> 
> And some times (such as in certain Swing/AWT code) they would 
> immediately affect something, eg. setting the text on a window would 
> immediately send a message to the rendering engine and make a change 
> happen the next time the window was painted.
> 
> Overall it wasn't a fault with Java, just with the Java programmers. 
> They were so used to using getFoo/setFoo they just used it all the time.

Great point. This getFoo/setFoo crap is so retarded. It is a good 
illustration of the road to hell paved with good intentions. Yes, it's 
good to give the object a crack to enforce its invariant upon setting 
and maybe to compute/adjust a value upon getting. Here things took the 
wrong turn in Java - instead of unifying fields with properties, they 
postulated there must be no public fields.


Andrei