Jarrett Billingsley escribió:
> On Sun, Dec 7, 2008 at 7:12 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>>> definition of toString that does match.  Most of the time ADL leads to
>>> confusing behavior, which is why it was dropped in D.
>> But the overloading is obvious! It looks for toString(...) and it founds it
>> in the class, but the overloading is wrong. So for me, it should keep
>> looking in the enclosing scopes.
> 
> That's why I said "*most* of the time" ;)  I'll agree that it's a bit
> counterintuitive, but I'd rather have the compiler be a little stupid
> in this regard than to pay the price of unexpected function matches
> for a little bit of convenience.

Ah, I see. Well, I'd like to see such an example then. :-P

Ary Borenszweig wrote:
> Jarrett Billingsley escribió:
>> On Sun, Dec 7, 2008 at 7:12 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>>>> definition of toString that does match.  Most of the time ADL leads to
>>>> confusing behavior, which is why it was dropped in D.
>>> But the overloading is obvious! It looks for toString(...) and it founds it
>>> in the class, but the overloading is wrong. So for me, it should keep
>>> looking in the enclosing scopes.
>>
>> That's why I said "*most* of the time" ;)  I'll agree that it's a bit
>> counterintuitive, but I'd rather have the compiler be a little stupid
>> in this regard than to pay the price of unexpected function matches
>> for a little bit of convenience.
> 
> Ah, I see. Well, I'd like to see such an example then. :-P

It usually won't be an issue, I think. You'll give your functions descriptive names, and you won't have overloads in different scopes that take similar arguments. So any example I give will probably seem contrived. I certainly have only encountered this compiler error a bare handful of times, and only with toString.

That said, errors of this kind would be difficult to track down, and the workaround is very simple once you know it -- and not that difficult to come up with if you don't. I think I came up using .toString without having anyone tell me about it, and if I hadn't, I would have used the fully qualified name (or an alias).

"Christopher Wright" <dhasenan@gmail.com> wrote in message news:ghhbn3$2u32$1@digitalmars.com...
> Ary Borenszweig wrote:
>> Jarrett Billingsley escribió:
>>> On Sun, Dec 7, 2008 at 7:12 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:
>>>>> definition of toString that does match.  Most of the time ADL leads to confusing behavior, which is why it was dropped in D.
>>>> But the overloading is obvious! It looks for toString(...) and it
>>>> founds it
>>>> in the class, but the overloading is wrong. So for me, it should keep
>>>> looking in the enclosing scopes.
>>>
>>> That's why I said "*most* of the time" ;)  I'll agree that it's a bit counterintuitive, but I'd rather have the compiler be a little stupid in this regard than to pay the price of unexpected function matches for a little bit of convenience.
>>
>> Ah, I see. Well, I'd like to see such an example then. :-P
>
> It usually won't be an issue, I think. You'll give your functions descriptive names, and you won't have overloads in different scopes that take similar arguments. So any example I give will probably seem contrived. I certainly have only encountered this compiler error a bare handful of times, and only with toString.
>
> That said, errors of this kind would be difficult to track down, and the workaround is very simple once you know it -- and not that difficult to come up with if you don't. I think I came up using .toString without having anyone tell me about it, and if I hadn't, I would have used the fully qualified name (or an alias).

I kind of like Ruby's requirement that accessing "this.whatever" *must* be done like "@whatever" (with the "this." part not being needed). Omitting the @ means you're talking about either a local identifier or a global one. I don't know if that stuff applies to member functions as well or if it's just member vars, but if it did apply to member funcs then that would certainly solve the "finding the correct toString" issue. Of course, that would probably be way too big of a syntax change for D, though.

Nick Sabalausky:
> I kind of like Ruby's requirement that accessing "this.whatever" *must* be done like "@whatever" (with the "this." part not being needed). Omitting the @ means you're talking about either a local identifier or a global one. I don't know if that stuff applies to member functions as well or if it's just member vars, but if it did apply to member funcs then that would certainly solve the "finding the correct toString" issue. Of course, that would probably be way too big of a syntax change for D, though.

In Ruby you also use @@ for class variables (similar to static attributes of classes in D).
I have often seen C++ code where the name of instance attributes are prefixed by "m_".
In D now and then I use "this.somename" to avoid name clashes (for example with argument variables) or to make more explicit that a variable isn't local.
Using a default prefix, like @ or $ to instance attributes in D2 code will make such code look a little ugly, but probably also more explicit too. (It's also short, shorter than "m_" and shorter than "this."). So I may end liking this syntax change.

Bye,
bearophile

Sat, 6 Dec 2008 13:04:56 -0500, Jarrett Billingsley wrote:

> On Sat, Dec 6, 2008 at 12:11 PM, Jerry <jlquinn@optonline.net> wrote:
>> Jarrett Billingsley Wrote:
>>
>>> On Sat, Dec 6, 2008 at 11:21 AM, Jerry <jlquinn@optonline.net> wrote:
>>> > toString() doesn't work inside a class member function.
>>> >
>>> > import std.string;
>>> > class A {
>>> >  void f() {
>>> >    string s = toString(5);
>>> >  }
>>> > }
>>> >
>>> > This errors with junk.d(19): function object.Object.toString () does not match parameter types (int)
>>> >
>>> > This is a nuisance and a wart (though not a bug per-se).
>>> >
>>> > If the language really can't handle distinguishing this.toString() from toString(int), then std.string.toString really should have a different name.
>>
>> As I'm thinking about this, why does this actually fail?  The parameter doesn't match the prototype for this.toString(), so why not match against the global function?
>>
>> Is this due to the behavior that override solves?  Would marking Object.toString() as override fix the problem?
>>
>>
> 
> As far as I know, it's because D does not use ADL (argument-dependent lookup).  That is, it simply looks for the toString that is in the nearest enclosing scope, and if it doesn't match - too bad.  Compare this behavior to C++, where it would then continue on, looking for a definition of toString that does match.

Not correct.  C++ uses the same rules to build overload sets as D.  That is, a function declaration in an inner scope hides any function declarations with the same name in outer scopes.  I /think/ there should be a good rationale behind this design.

Actually, any declaration works like this.  A variable declaration hides any declarations with the same name in the outer scopes.  Probably functions follow this rule to make overloading more predictable.

Sergey Gromov wrote:
> Not correct.  C++ uses the same rules to build overload sets as D.  That
> is, a function declaration in an inner scope hides any function
> declarations with the same name in outer scopes.  I /think/ there should
> be a good rationale behind this design.

I've been using C++ lately, and I'd put it a bit differently:
I think there /should/ be a good rationale behind its design.

On Sun, Dec 7, 2008 at 5:54 PM, Sergey Gromov <snake.scaly@gmail.com> wrote:
> Sat, 6 Dec 2008 13:04:56 -0500, Jarrett Billingsley wrote:
>
>> On Sat, Dec 6, 2008 at 12:11 PM, Jerry <jlquinn@optonline.net> wrote:
>>> Jarrett Billingsley Wrote:
>>>
>>>> On Sat, Dec 6, 2008 at 11:21 AM, Jerry <jlquinn@optonline.net> wrote:
>>>> > toString() doesn't work inside a class member function.
>>>> >
>>>> > import std.string;
>>>> > class A {
>>>> >  void f() {
>>>> >    string s = toString(5);
>>>> >  }
>>>> > }
>>>> >
>>>> > This errors with junk.d(19): function object.Object.toString () does not match parameter types (int)
>>>> >
>>>> > This is a nuisance and a wart (though not a bug per-se).
>>>> >
>>>> > If the language really can't handle distinguishing this.toString() from toString(int), then std.string.toString really should have a different name.
>>>
>>> As I'm thinking about this, why does this actually fail?  The parameter doesn't match the prototype for this.toString(), so why not match against the global function?
>>>
>>> Is this due to the behavior that override solves?  Would marking Object.toString() as override fix the problem?
>>>
>>>
>>
>> As far as I know, it's because D does not use ADL (argument-dependent lookup).  That is, it simply looks for the toString that is in the nearest enclosing scope, and if it doesn't match - too bad.  Compare this behavior to C++, where it would then continue on, looking for a definition of toString that does match.
>
> Not correct.  C++ uses the same rules to build overload sets as D.  That is, a function declaration in an inner scope hides any function declarations with the same name in outer scopes.  I /think/ there should be a good rationale behind this design.
>
> Actually, any declaration works like this.  A variable declaration hides any declarations with the same name in the outer scopes.  Probably functions follow this rule to make overloading more predictable.
>

Sorry.