Why are opCall's not implicitely assignable?

Ivan Senji ivan.senji_REMOVE_ at _THIS__gmail.com
Wed Sep 27 10:05:24 PDT 2006


Karen Lanrap wrote:
> Ivan Senji wrote:
> 
>> IMO (and knowing this NG) this is about a point in time where
>> you will stop getting responses to your posts. It usually has
>> something to do with a person refusing to understand a principal
>> as basic as this one.
> 
> I already noticed that this NG is filled with posters refusing to 
> understand simple principles---but willing to press others into 
> principles they believe to be simple.

Well that depends on ones point of view ;)

> 
> This whole thread showed, that near to none is able to capture that 
> a property might have a complex structure. So complex that it might 
> be best expressed by the most complex structure of D: a class.

I get this, probably most projects have properties that are classes.
And classes are reference types. Allowing opCall to be called in a 
property style would effectively mean overloading assignment which makes 
no sense for reference types.

No-overloading-of-assignment is a rule in D for a good reason, and 
allowing to go around this rule would be plain evil.


>> It is all up to you:
> 
> No, it is not. D prohibits me to code the way I think. 

Which new language doesn't make you think (at least sometimes) in a new 
way? (Change the way you think)

> And the 
> posters in this thread want not only themselves beeing forced to 
> read the name of the same property over and over again, they also 
> force others to code superfluous words---and at the same time they 
> admire that they can replace a pair of parentheses by an equal 
> sign.
> 

Superfluous to someone is readable and self-documenting to someone else.

> That's mental inconsistency at its best.

Nowhere it is said that assignment can be overloaded (it can't be), and 
nowhere it is said that opCall is a property. Things would be 
inconsistent if
a(5) and a.opCall(5) worked and a.opCall = 5; didn't work.

This way there is no inconsistency.

Mental inconsistencies sometimes mean you have to accept something 
and/or change the way you think. Changing to D-thinking will free your 
mind (when compared for example to C++ programming)

> 
> Nobody even cared about the fact, that D is also intended for large 
> scale projects which might include british and american style 
> pronounciations, forcing every maintainer to exactly know whether 
> to write color or colour.

And this doesn't have anything to do with anything,
ideally a library should have only one name and be consistent with it. 
But nothing prevents you from having

struct color{}
alias color colour;

And now anyone can write what ever they prefer.

> 
> 
>> What point?
> 
> Ever heard of the module scope operator

I get it now.

> or the D-style to 
> separate an operator by one space from its operands?

And now I don't get what this means.

But I found out where the story about a "." comes from, Derek accidently 
left if in his example, and if he or anyone else tried to compile it he 
would get an error from the compiler about something not being a part of 
global scope. No disaster.



More information about the Digitalmars-d-learn mailing list