View mode: basic / threaded / horizontal-split · Log in · Help
December 28, 2005
Re: Operator Overloading
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/
December 28, 2005
Re: Operator Overloading
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.
December 29, 2005
Re: Operator Overloading
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.
December 29, 2005
Re: Operator Overloading
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.
December 29, 2005
Re: Operator Overloading
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.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home