Community

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.

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?

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.

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.

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.

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

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.

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!

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

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