www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Operator Overloading

reply dyh inbox.lv writes:
Hi all,

I've got one concern about language syntax - overloading. As I understand these
so called 'opfunc's (opCom etc...) are some kind of 'reserved' or 'native'
methods. 

So, it is strange that they are semantically indistinguishable from user
functions. Why not no name them like _opCom to clearly show they they are for
special purpose. In my opinion that way its clearer to read and less confusing.
And there should be convention not to name user functions that way.

I'm not insist on what exact notation should be used, but I believe all 'magic'
methods should have common syntax, that differ from user methods.

DYH.
Dec 27 2005
next sibling parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
dyh inbox.lv wrote:


 I'm not insist on what exact notation should be used, but I believe all
 'magic' methods should have common syntax, that differ from user methods.


Wasn't prefix "op" inserted to do the job?
Dec 27 2005
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Dawid Ciężarkiewicz wrote:

 dyh inbox.lv wrote:
 
 

I'm not insist on what exact notation should be used, but I believe all
'magic' methods should have common syntax, that differ from user methods.


 
 
 Wasn't prefix "op" inserted to do the job?


Yes, but the valid point is that to the untrained D programmer's eye it 
still looks like a regular user function.  One could ask: why is "a + b" 
valid if a and b define an opAdd function?

While I agree that it is somewhat unclear to the beginner, it is clearly 
stated in the documentation.  Also, I don't agree with the leading 
underscore prefix idea.  This looks (to me) like a system-reserved 
function name, not a language-reserved one.  But that's probably because 
I'm not a beginner.
Dec 27 2005
parent dyh inbox.lv writes:
In article <dos7si$16dk$1 digitaldaemon.com>, James Dunne says...


While I agree that it is somewhat unclear to the beginner, it is clearly 
stated in the documentation.  Also, I don't agree with the leading 
underscore prefix idea.  This looks (to me) like a system-reserved 
function name, not a language-reserved one.


Yes, it may looks like a system function if it was actually a function, but it
is a method, and in this case it's looks more like it is a special language
feature.


But that's probably because I'm not a beginner.


Neither am I. But it is not bear on this case. The point is to make language
semantics clearer. It should be good for all users, and as so, for language
itself.

DYH.
Dec 27 2005
prev sibling parent reply dyh inbox.lv writes:
In article <dos05q$104r$1 digitaldaemon.com>, Dawid
=?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= says...

dyh inbox.lv wrote:


 I'm not insist on what exact notation should be used, but I believe all
 'magic' methods should have common syntax, that differ from user methods.


Wasn't prefix "op" inserted to do the job?


I think it is not. opSomething sounds just like getSomethong or doSomething. It
is like ordinary user method. But __opSomething is.

My point is that special methods (operator overloaders, or serializers, or
whatever language feature) should be distinct from user defined methods/fields.
And therefore should not be called directly by user.

DYH.
Dec 27 2005
parent reply "Derek Parnell" <derek psych.ward> writes:
On Wed, 28 Dec 2005 07:56:38 +1100, <dyh inbox.lv> wrote:


 In article <dos05q$104r$1 digitaldaemon.com>, Dawid
 =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= says...

 dyh inbox.lv wrote:


 I'm not insist on what exact notation should be used, but I believe all
 'magic' methods should have common syntax, that differ from user  
 methods.


 Wasn't prefix "op" inserted to do the job?


 I think it is not. opSomething sounds just like getSomethong or  
 doSomething. It
 is like ordinary user method. But __opSomething is.

 My point is that special methods (operator overloaders, or serializers,  
 or
 whatever language feature) should be distinct from user defined  
 methods/fields.


Yes, this makes sense to me too. A simple way would be to include a  
character that is otherwise not permitted in identifier names. For example  
... op~Add.

One reason to support this idea is the sitatuion where someone innocently  
creates a member called 'opDup' and sometime later the language is  
enhanced to include a 'copy'/'dup' operator. Bang code will suddenly break  
due to no fault of the coder.


 And therefore should not be called directly by user.


I'm not so sure about this aspect. The use of delegates for the 'op'  
members could be useful.


-- 
Derek Parnell
Dec 27 2005
next sibling parent dyh inbox.lv writes:
In article <op.s2govcry6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...


One reason to support this idea is the sitatuion where someone innocently  
creates a member called 'opDup' and sometime later the language is  
enhanced to include a 'copy'/'dup' operator. Bang code will suddenly break  
due to no fault of the coder.


Indeed. The methods with this special notation should be predefined by language
only - user should not use that notation to define own methods. Just to stay out
of this kind of troubles, and to keep code clear. Of course by convention, not
by force. 


 And therefore should not be called directly by user.


I'm not so sure about this aspect. The use of delegates for the 'op'  
members could be useful.


Ok, I'm not sure too :) Actually I can't imagine situation where operator
overload needed to be called directly. Perhaps when user inherit this methods hi
may want to use them in some cases. Anyway, when I said "should not be called
directly by user" I mean should not, but can be, if he need it for some reason.

DYH.
Dec 27 2005
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Derek Parnell wrote:

[...]

 One reason to support this idea is the sitatuion where someone
 innocently  creates a member called 'opDup' and sometime later
 the language is  enhanced to include a 'copy'/'dup' operator.
 Bang code will suddenly break  due to no fault of the coder.


[...]

Then this is also a reason for not having any keywords.

-manfred
Dec 28 2005
parent "Derek Parnell" <derek psych.ward> writes:
On Wed, 28 Dec 2005 20:13:55 +1100, Manfred Nowak <svv1999 hotmail.com>  
wrote:


 Derek Parnell wrote:

 [...]

 One reason to support this idea is the sitatuion where someone
 innocently  creates a member called 'opDup' and sometime later
 the language is  enhanced to include a 'copy'/'dup' operator.
 Bang code will suddenly break  due to no fault of the coder.


 [...]

 Then this is also a reason for not having any keywords.


Yes. Exactly! But since that is not going to happen anytime soon, I choose  
to adopt a naming convention for *my* identifiers that minimizes  
collisions with potential and existing keywords.

The 'op' prefix for D's special functions is not something I have control  
over. So putting both these things together, I will not be naming member  
functions as 'op'SomethingOrOther.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 28 2005
prev sibling parent Bruno Medeiros <daip lycos.com> writes:
Derek Parnell wrote:

 On Wed, 28 Dec 2005 07:56:38 +1100, <dyh inbox.lv> wrote:
 

 In article <dos05q$104r$1 digitaldaemon.com>, Dawid
 =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= says...


 dyh inbox.lv wrote:


 I'm not insist on what exact notation should be used, but I believe all
 'magic' methods should have common syntax, that differ from user  
 methods.



 Wasn't prefix "op" inserted to do the job?



 I think it is not. opSomething sounds just like getSomethong or  
 doSomething. It
 is like ordinary user method. But __opSomething is.

 My point is that special methods (operator overloaders, or 
 serializers,  or
 whatever language feature) should be distinct from user defined  
 methods/fields.


 
 
 Yes, this makes sense to me too. A simple way would be to include a  
 character that is otherwise not permitted in identifier names. For 
 example  .... op~Add.
 
 One reason to support this idea is the sitatuion where someone 
 innocently  creates a member called 'opDup' and sometime later the 
 language is  enhanced to include a 'copy'/'dup' operator. Bang code will 
 suddenly break  due to no fault of the coder.
 


Why would the code break? opDup wouldn't become uncallable by normal 
means, and the dup operator overload wasn't being used since it didn't 
exist before. It might affect future development, but not break existing 
code.
Also, in any case, I don't think that any compatibility problems should 
influence the language design while it is still in development.
Dec 29 2005
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
dyh inbox.lv wrote:

 Hi all,
 
 I've got one concern about language syntax - overloading. As I understand these
 so called 'opfunc's (opCom etc...) are some kind of 'reserved' or 'native'
 methods. 
 
 So, it is strange that they are semantically indistinguishable from user
 functions. Why not no name them like _opCom to clearly show they they are for
 special purpose. In my opinion that way its clearer to read and less confusing.
 And there should be convention not to name user functions that way.
 
 I'm not insist on what exact notation should be used, but I believe all 'magic'
 methods should have common syntax, that differ from user methods.
 
 DYH.


I disagree, totally!

underscore prefixes are UGLY and too many _ are combursome to type (you 
have to reach all the way up and hold the shift button :p)

As for beginners, well, they probably wouldn't even understand what a 
class is!! so why bother!! Plus, a decent IDE/TextEditor can highlight 
op* methods, just as well as it can highlight "class" and all other 
keywords.

I love the way Walter implemented Operator Overloading .. and I would 
really hate for it to change!
Dec 27 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Hasan Aljudy wrote:

[...]

 I disagree, totally!


[...]

I totally agree with your disagreeing.

Every scheme for indicating the type of an identifier should stay at 
the personal preference of each person.

The OP can use as many underscores as he want in the identifieres 
used by him to distinguish them from reserved or predefind 
identifiers of D.

-manfred
Dec 28 2005
parent dyh inbox.lv writes:
In article <Xns973A697B636Dsvv1999hotmailcom 63.105.9.61>, Manfred Nowak says...


Every scheme for indicating the type of an identifier should stay at 
the personal preference of each person.

The OP can use as many underscores as he want in the identifieres 
used by him to distinguish them from reserved or predefind 
identifiers of D.


Sorry for bothering You, but this is common practice in most languages - to
distinct special identifiers from user defined. 

Quote from D language manual (http://digitalmars.com/d/lex.html):
"Identifiers starting with __ (two underscores) are reserved."

This is not reserved keywords, but naming convention.

In my opinion, such naming convention may be used for some methods too. For
methods reserved for language's special features. And operator overloading is
one of such features.

DYH.
Dec 28 2005
prev sibling parent reply Bruno Medeiros <daip lycos.com> writes:
dyh inbox.lv wrote:

 Hi all,
 
 I've got one concern about language syntax - overloading. As I understand these
 so called 'opfunc's (opCom etc...) are some kind of 'reserved' or 'native'
 methods. 
 
 So, it is strange that they are semantically indistinguishable from user
 functions. Why not no name them like _opCom to clearly show they they are for
 special purpose. In my opinion that way its clearer to read and less confusing.
 And there should be convention not to name user functions that way.
 
 I'm not insist on what exact notation should be used, but I believe all 'magic'
 methods should have common syntax, that differ from user methods.
 
 DYH.


I disagree (with the change). Operator functions are semantically (I 
think you meant _syntatically_) indistinguishable from normal functions, 
because they are not really different from normal functions: They also 
are functions and they also can be called like normal functions ( like: 
fooA.opAdd(fooB); ). The only difference is that they have an 
alternative, sintatic-sugar way to be called, but I don't think that's 
difference enough to justify a different syntax or namespace.
And that's the beauty of it: D's design simplicity of operator functions.
Dec 29 2005
parent dyh inbox.lv writes:
In article <dp0q8t$8i8$1 digitaldaemon.com>, Bruno Medeiros says...

I disagree (with the change). Operator functions are semantically (I 
think you meant _syntatically_) indistinguishable from normal functions, 
because they are not really different from normal functions: They also 
are functions and they also can be called like normal functions ( like: 
fooA.opAdd(fooB); ). The only difference is that they have an 
alternative, sintatic-sugar way to be called, but I don't think that's 
difference enough to justify a different syntax or namespace.
And that's the beauty of it: D's design simplicity of operator functions.


I mean semantically, as "semantics is the study of meaning, in some sense of
that term" - from wikipedia. 
I wish that for special methods will be special naming convention (not syntax).
'opCmp' in more like common rather special name.

DYH.
Dec 29 2005