J C Calvarese wrote:
> I can't see much of a benefit to allow this on A and B classes, when a person can already achieve this functionality by defining a method. Actually, I suspect it's a bad idea to allow this on classes and structs. I'm also not sure how it should affect fixed arrays.

OK, that would be the smaller solution: just make a.something(b,c) syntactic sugar for something(a,b,c) in those cases where a is neither a struct nor a class. That should not cause any trouble, I think. It does not break any existing code.

I really start to like that idea. It always seemed somewhat odd to me that certain types have properties, but you could not add others in the library. It would also help answering the question whether properties like .sort might be better moved to the library, since this would not affect the user at all any more.

Norbert Nemec wrote:

> The big advantage I see there, is that you can finally stop thinking about
> whether to make a certain feature a method or a free function. There would
> not be any difference between str.length, str.length() or length(str)

The benefits are there, I agree.  I am more concerned with just how easy this is to misuse.

I would be happier if the primitive types had a stable, well-known set of operations defined within the language (and/or standard library).  I can see myself looking at code later and thinking "what the hell, strings don't do that", then later realizing that it's probably a free function defined... someplace.

However, I am having a hard time rationalizing my opinion.  I may need to reevaluate it.

 -- andy

>For example, it
>might be appealing to people who like this aspect of Java.

Oh does Java do this ?  I just tried and couldnt get it to work, but im only 3 days into Java, so its probably something im missing.

Charlie

In article <c8ajt1$3081$1@digitaldaemon.com>, J C Calvarese says...
>
>In article <c8ah78$2sd9$1@digitaldaemon.com>, Norbert Nemec says...
>>
>>Ivan Senji wrote:
>>
>>> Again i can only say "Please make this work in general" and i don't
>>> think it is short-sighted, actually i am looking very far into the
>>> possiblities
>>> of this feature, but in the case i am wrong i will probbably get good
>>> answers and explanations why this isn't a good feature and what possible
>>> problems can it cause :)
>>
>>It is hard to pinpoint problems without a clear idea what we are talking about. For example:
>>
>>Would
>>        a.f(b,c)
>>and
>>        f(a,b,c)
>>
>>be absolutely identical in any case? This would make free functions identical to non-virtual functions in C++. It would have to be illegal to define colliding methods and free functions.
>>
>>If you have nested namespaces, this would break existing code without giving any error messages:
>>
>>------------------
>>class A {
>>        void f() { ... }
>>};
>>
>>class B {
>>        void f(A a) { ... }
>>
>>        void x(A a) { f(a); a.f(); }
>>};
>>------------------
>>
>>what would happen in this case?
>>
>>I really like the idea, but as you see, it would have tremendous impact on the language as a whole.
>
>I can't see much of a benefit to allow this on A and B classes, when a person can already achieve this functionality by defining a method. Actually, I suspect it's a bad idea to allow this on classes and structs. I'm also not sure how it should affect fixed arrays.
>
>We can already use these tricks with char[] and int[] (and I haven't read any bug reports relating to this yet). I wonder if it'd cause problems to allow this syntax with int, uint, char, bit, etc. I can see some benefits. For example, it might be appealing to people who like this aspect of Java.
>
>I'm not saying we NEED this "syntactic sugar", but I like the idea, and I'm curious what the actual downside should be. (Yes, I know everything has a cost, but the cost might be low.)
>
>jcc7

Andy Friesen wrote:

> Norbert Nemec wrote:
> 
>> The big advantage I see there, is that you can finally stop thinking about whether to make a certain feature a method or a free function. There would not be any difference between str.length, str.length() or length(str)
> 
> The benefits are there, I agree.  I am more concerned with just how easy this is to misuse.
> 
> I would be happier if the primitive types had a stable, well-known set of operations defined within the language (and/or standard library).  I can see myself looking at code later and thinking "what the hell, strings don't do that", then later realizing that it's probably a free function defined... someplace.
> 
> However, I am having a hard time rationalizing my opinion.  I may need to reevaluate it.

I don't quite understand your position: I would guess that everyone agrees with your statement as long as you include the words "and/or standard library" - of course stuff like .length must be well defined, but I believe that the language should try to define only the absolutely bare minimum and leave as much as possible to the library, unless there are good reasons (like performance or special syntax) to do otherwise. I guess, .length is part of the minimal interface of arrays, so this one should really go into the language definition.

Of course, D needs a well-defined standard library to work. And if you override parts of that library, you should really know what you are doing. But that still is the allow-anyone-to-shoot-himself-in-the-foot attitude of D...

Norbert Nemec wrote:
> I don't quite understand your position: I would guess that everyone agrees
> with your statement as long as you include the words "and/or standard
> library" - of course stuff like .length must be well defined, but I believe
> that the language should try to define only the absolutely bare minimum and
> leave as much as possible to the library, unless there are good reasons
> (like performance or special syntax) to do otherwise. I guess, .length is
> part of the minimal interface of arrays, so this one should really go into
> the language definition.

Take std.string for example.  A lot of the functions there behave, and are conveniently used as though they were methods of char[].  That's all well and good, but, if anybody can add to those operations just by defining a function, the 'interface' for char[] depends purely on what imports are in the current scope.

> Of course, D needs a well-defined standard library to work. And if you
> override parts of that library, you should really know what you are doing.
> But that still is the allow-anyone-to-shoot-himself-in-the-foot attitude of
> D...

I like to think of D's approach as "allow anyone to shoot himself in the foot if he's really sure that's what he wants, but make it hard to do accidentally".

 -- andy

Andy Friesen wrote:

> Norbert Nemec wrote:
>> I don't quite understand your position: I would guess that everyone agrees with your statement as long as you include the words "and/or standard library" - of course stuff like .length must be well defined, but I believe that the language should try to define only the absolutely bare minimum and leave as much as possible to the library, unless there are good reasons (like performance or special syntax) to do otherwise. I guess, .length is part of the minimal interface of arrays, so this one should really go into the language definition.
> 
> Take std.string for example.  A lot of the functions there behave, and are conveniently used as though they were methods of char[].  That's all well and good, but, if anybody can add to those operations just by defining a function, the 'interface' for char[] depends purely on what imports are in the current scope.

Does it hurt if an interface is freely extendable? If you don't use a feature, you don't have to worry if it is there. The only problem that might occur is, that you want to use a feature and don't know what to import for it. But that problem is the same whether the feature is called via .something or via something()

One only has to rethink when coming from C++, where .something always is a feature defined within a class or struct. But that has already changed with the introduction of properties of fundamental types.

>> Of course, D needs a well-defined standard library to work. And if you override parts of that library, you should really know what you are doing. But that still is the allow-anyone-to-shoot-himself-in-the-foot attitude of D...
> 
> I like to think of D's approach as "allow anyone to shoot himself in the foot if he's really sure that's what he wants, but make it hard to do accidentally".

True. Sorry for the abbreviated citation...

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c8ah78$2sd9$1@digitaldaemon.com...
> Ivan Senji wrote:
>
> > Again i can only say "Please make this work in general" and i don't
> > think it is short-sighted, actually i am looking very far into the
> > possiblities
> > of this feature, but in the case i am wrong i will probbably get good
> > answers and explanations why this isn't a good feature and what possible
> > problems can it cause :)
>
> It is hard to pinpoint problems without a clear idea what we are talking about. For example:
>
> Would
>         a.f(b,c)
> and
>         f(a,b,c)
>
> be absolutely identical in any case? This would make free functions identical to non-virtual functions in C++. It would have to be illegal to define colliding methods and free functions.
>
> If you have nested namespaces, this would break existing code without
giving
> any error messages:
>
> ------------------
> class A {
>         void f() { ... }
> };
>
> class B {
>         void f(A a) { ... }
>
>         void x(A a) { f(a); a.f(); }
> };
> ------------------
>
> what would happen in this case?
>
> I really like the idea, but as you see, it would have tremendous impact on the language as a whole.
>

The D-way of dealing with be to define a simple rule: either report
that the code is ambigous or define a simple rule for example,
a.f() first look for f() in a, and then if not found look for f(a).

But thinking a little bit more about this i agree with you that it would be good if this worked for non-struct and non-class types.

Although it could be useful sometimes with classes also :)

In article <c8aril$b1t$1@digitaldaemon.com>, Charlie says...
>
>>For example, it
>>might be appealing to people who like this aspect of Java.
>
>Oh does Java do this ?  I just tried and couldnt get it to work, but im only 3 days into Java, so its probably something im missing.
>
>Charlie

Well, not exactly.

What I mean is that Java's String class has a toUpper and toLower that are accessed with a dot: e.g. myString.toUpper. So I exagerated the new way's similarity to Java. It just looks "Javish" to me.

jcc7

>
>In article <c8ajt1$3081$1@digitaldaemon.com>, J C Calvarese says...
>>
>>In article <c8ah78$2sd9$1@digitaldaemon.com>, Norbert Nemec says...
>>>
>>>Ivan Senji wrote:
>>>
>>>> Again i can only say "Please make this work in general" and i don't
>>>> think it is short-sighted, actually i am looking very far into the
>>>> possiblities
>>>> of this feature, but in the case i am wrong i will probbably get good
>>>> answers and explanations why this isn't a good feature and what possible
>>>> problems can it cause :)
>>>
>>>It is hard to pinpoint problems without a clear idea what we are talking about. For example:
>>>
>>>Would
>>>        a.f(b,c)
>>>and
>>>        f(a,b,c)
>>>
>>>be absolutely identical in any case? This would make free functions identical to non-virtual functions in C++. It would have to be illegal to define colliding methods and free functions.
>>>
>>>If you have nested namespaces, this would break existing code without giving any error messages:
>>>
>>>------------------
>>>class A {
>>>        void f() { ... }
>>>};
>>>
>>>class B {
>>>        void f(A a) { ... }
>>>
>>>        void x(A a) { f(a); a.f(); }
>>>};
>>>------------------
>>>
>>>what would happen in this case?
>>>
>>>I really like the idea, but as you see, it would have tremendous impact on the language as a whole.
>>
>>I can't see much of a benefit to allow this on A and B classes, when a person can already achieve this functionality by defining a method. Actually, I suspect it's a bad idea to allow this on classes and structs. I'm also not sure how it should affect fixed arrays.
>>
>>We can already use these tricks with char[] and int[] (and I haven't read any bug reports relating to this yet). I wonder if it'd cause problems to allow this syntax with int, uint, char, bit, etc. I can see some benefits. For example, it might be appealing to people who like this aspect of Java.
>>
>>I'm not saying we NEED this "syntactic sugar", but I like the idea, and I'm curious what the actual downside should be. (Yes, I know everything has a cost, but the cost might be low.)
>>
>>jcc7
>
>

J C Calvarese wrote:
> In article <c8aril$b1t$1@digitaldaemon.com>, Charlie says...
> 
>>>For example, it
>>>might be appealing to people who like this aspect of Java.
>>
>>Oh does Java do this ?  I just tried and couldnt get it to work, but im only 3
>>days into Java, so its probably something im missing.
>>
>>Charlie
> 
> 
> Well, not exactly.
> 
> What I mean is that Java's String class has a toUpper and toLower that are
> accessed with a dot: e.g. myString.toUpper. So I exagerated the new way's
> similarity to Java. It just looks "Javish" to me.

Eh? Accessing member methods with a dot is "Javaish"? It's also "D-ish", "C++-ish", "C#-ish", "Pythonesque", "Luarish" and "just about any other OO language"-ish ;).

Hauke

Hauke Duden wrote:

> J C Calvarese wrote:
> 
>> In article <c8aril$b1t$1@digitaldaemon.com>, Charlie says...
>>
>>>> For example, it
>>>> might be appealing to people who like this aspect of Java.
>>>
>>>
>>> Oh does Java do this ?  I just tried and couldnt get it to work, but im only 3
>>> days into Java, so its probably something im missing.
>>>
>>> Charlie
>>
>>
>>
>> Well, not exactly.
>>
>> What I mean is that Java's String class has a toUpper and toLower that are
>> accessed with a dot: e.g. myString.toUpper. So I exagerated the new way's
>> similarity to Java. It just looks "Javish" to me.
> 
> 
> Eh? Accessing member methods with a dot is "Javaish"? It's also "D-ish", 

Actually, I used the less-common expression "Javish" rather than "Javaish". (Not that it matters.)

> "C++-ish", "C#-ish", "Pythonesque", "Luarish" and "just about any other OO language"-ish ;).
> 
> Hauke

Maybe it's my lack of knowledge in C++, C#, Python, Lua, and Smalltalk. :)






-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/