March 07, 2005
"John Demme" <me@teqdruid.com> wrote in message news:d0i1rd$2t1f$1@digitaldaemon.com...
>I thought that one needed to manually override the method in any situation where the child class's method's parameter was a child of the parent's method's parameter... ie:
> import std.stdio;
>
> class C {
>   void foo(C c) {
>     writefln("C");
>   }
> }
>
> class B: C {
>   void foo(B b) {
>     writefln("B");
>   }
> }
>
> void main() {
>         C b = new B();
>         b.foo(b);
> }
>
> Prints "C", when I think it should print "B".  Is this something that D will do eventually, or no?

It would be very hard to do with the standard vtable mechanism (I think). The call b.foo(b) compiles into basically "take the vtable for b and call the first function in the C section" since the type of b is C and the first function of C is foo. To implement what you suggest using that same mechanism the function B.foo would have to be stored in the slot for C.foo - which is illegal since users can pass *any* object of type C to C.foo but not B.foo (if I have that written straight). So I would imagine some sort of double dispatching would be needed to implement what you suggest.

> John
>
> Walter wrote:
>> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:d0hbh4$250h$1@digitaldaemon.com...
>>
>>>IMO, 3. is the only sane solution. It's the same problem with the stinky
>>
>> crap of opCmp. Look at the rubbish I've had to
>>
>>>write to get comparable Fields:
>>
>>
>>
>> You only need opCmp(Object) if you are using builtin operations like
>> .sort.
>> If you're going to use < or > operators with Fields, then opCmp(Field) is
>> all you need.
>> 

March 07, 2005
"Walter" <newshound@digitalmars.com> wrote in message news:d0i8qe$3ml$2@digitaldaemon.com...
>
> "John Demme" <me@teqdruid.com> wrote in message news:d0i1rd$2t1f$1@digitaldaemon.com...
>> Prints "C", when I think it should print "B".  Is this something that D will do eventually, or no?
>
> What you're asking for is Java style overloading. D does C++ style overloading. There's been heated debate about which is better.

I think the issue is about overriding not overloading. It's probably some
form of "covariance" but I'm not an expert on that stuff. The function call
in main() uses C as the declared type
         C b = new B();
         b.foo(b);


March 07, 2005
Walter wrote:
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message
> news:d0hbh4$250h$1@digitaldaemon.com...
> 
>>IMO, 3. is the only sane solution. It's the same problem with the stinky
> 
> crap of opCmp. Look at the rubbish I've had to
> 
>>write to get comparable Fields:
> 
> 
> 
> You only need opCmp(Object) if you are using builtin operations like .sort.
> If you're going to use < or > operators with Fields, then opCmp(Field) is
> all you need.
> 
> 
Isn't this a pretty major inconsistancy?  There should only be One Right Way to write the opCmp function, and it should work across the language.  Of course, that's just MHO :)

Brad
March 07, 2005
Walter wrote:

>>We cannot afford to keep things like this. Period.
>>
>>In a newcomers eye, this sticks out so bad, he'll think the rest of the
>>language is the same. _We_ know it's not, but how do you convince them?
> 
> Javascript does it just that way, too.

Does what ? Set keys on lookup ? No, it doesn't.

test.ds:
> a = new Array();
> 
> a["one"] = 1;
> a["two"] = 2;
> a["three"] = 3;
> a["four"];
> 
> for (key in a)
>   println(key);

one
two
three

test.d:
> import std.stdio;
> 
> void main()
> {
> int[char[]] a;
> 
> a["one"] = 1;
> a["two"] = 2;
> a["three"] = 3;
> a["four"];
> 
> foreach (char[] key; a.keys)
>   writefln("%s", key);
> }

two
one
four
three

I think D (and rumor has it C++'s "map"?)
are the only ones that set keys on get...

--anders
March 07, 2005
<brad@domain.invalid> wrote in message news:d0ibse$6sc$1@digitaldaemon.com...
> Walter wrote:
>> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:d0hbh4$250h$1@digitaldaemon.com...
>>
>>>IMO, 3. is the only sane solution. It's the same problem with the stinky
>>
>> crap of opCmp. Look at the rubbish I've had to
>>
>>>write to get comparable Fields:
>>
>>
>>
>> You only need opCmp(Object) if you are using builtin operations like .sort.
>> If you're going to use < or > operators with Fields, then opCmp(Field) is
>> all you need.
>>
>>
> Isn't this a pretty major inconsistancy?  There should only be One Right Way to write the opCmp function, and it should work across the language. Of course, that's just MHO :)

Indeed. I'm pretty sure that I wrote DTL 0.2 to not use this disgusting hack. (I *HATE* things whose behaviours one cannot predict at compile time (and therefore cannot predict at all). To be fair to D, this is a flaw of Java and .NET also, and harder to obviate in them.) Even if I remember incorrectly (IRI??), I will ensure that DTL 0.3 does so. Then I will never have to write, or at least use, an opCmp(Object) ever again.



March 07, 2005
"Anders F Björklund" <afb@algonet.se> wrote in message news:d0icp0$86l$1@digitaldaemon.com...
> Walter wrote:
>
>>>We cannot afford to keep things like this. Period.
>>>
>>>In a newcomers eye, this sticks out so bad, he'll think the rest of the language is the same. _We_ know it's not, but how do you convince them?
>>
>> Javascript does it just that way, too.
>
> Does what ? Set keys on lookup ? No, it doesn't.
>
> test.ds:
>> a = new Array();
>>
>> a["one"] = 1;
>> a["two"] = 2;
>> a["three"] = 3;
>> a["four"];
>>
>> for (key in a)
>>   println(key);
>
> one
> two
> three
>
> test.d:
>> import std.stdio;
>>
>> void main()
>> {
>> int[char[]] a;
>>
>> a["one"] = 1;
>> a["two"] = 2;
>> a["three"] = 3;
>> a["four"];
>>
>> foreach (char[] key; a.keys)
>>   writefln("%s", key);
>> }
>
> two
> one
> four
> three
>
> I think D (and rumor has it C++'s "map"?)
> are the only ones that set keys on get...

C++ certainly does. And it STINKS!!!!!!!!!!!!!!

(For anyone that's interested, you can read all about my _reasoned_ arguments against in April's DDJ, in my article "C++ and operator []=".)

Walter, I say get some caffiene, gird your loins and brace yourself for a barrage with more fervour and passion than the warnings debate. This is at once a howling stinker, and an opportunity to genuinely improve on C++ (rather than doing something new and different).






March 07, 2005
C++'s map does it for sure , why I have no idea, seems like a horrible idea to me as well.  Just wanted to throw my vote in the 'No AA Writing on lookup' camp.

Charlie


"Anders F Björklund" <afb@algonet.se> wrote in message news:d0icp0$86l$1@digitaldaemon.com...
> Walter wrote:
>
> >>We cannot afford to keep things like this. Period.
> >>
> >>In a newcomers eye, this sticks out so bad, he'll think the rest of the language is the same. _We_ know it's not, but how do you convince them?
> >
> > Javascript does it just that way, too.
>
> Does what ? Set keys on lookup ? No, it doesn't.
>
> test.ds:
> > a = new Array();
> >
> > a["one"] = 1;
> > a["two"] = 2;
> > a["three"] = 3;
> > a["four"];
> >
> > for (key in a)
> >   println(key);
>
> one
> two
> three
>
> test.d:
> > import std.stdio;
> >
> > void main()
> > {
> > int[char[]] a;
> >
> > a["one"] = 1;
> > a["two"] = 2;
> > a["three"] = 3;
> > a["four"];
> >
> > foreach (char[] key; a.keys)
> >   writefln("%s", key);
> > }
>
> two
> one
> four
> three
>
> I think D (and rumor has it C++'s "map"?)
> are the only ones that set keys on get...
>
> --anders


March 07, 2005
<brad@domain.invalid> wrote in message news:d0ibse$6sc$1@digitaldaemon.com...
> Walter wrote:
> > You only need opCmp(Object) if you are using builtin operations like
.sort.
> > If you're going to use < or > operators with Fields, then opCmp(Field)
is
> > all you need.
> >
> >
> Isn't this a pretty major inconsistancy?  There should only be One Right
> Way to write the opCmp function, and it should work across the language.
>   Of course, that's just MHO :)

Any other way to do it just looks like a major inconsistent hack in itself.


March 07, 2005
Gack! You're right!


March 07, 2005
On Mon, 7 Mar 2005 22:37:19 +1100, Matthew <admin.hat@stlsoft.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm9maon623k2f5@nrage.netwin.co.nz...
>> On Mon, 7 Mar 2005 22:25:31 +1100, Matthew <admin.hat@stlsoft.dot.org>  wrote:
>>> "Regan Heath" <regan@netwin.co.nz> wrote in message  news:opsm9k23nq23k2f5@nrage.netwin.co.nz...
>>>> On Mon, 7 Mar 2005 21:49:42 +1100, Matthew <admin.hat@stlsoft.dot.org>   wrote:
>>>>> There are three options:
>>>>>
>>>>>     1. return .init
>>>>>     2. insert an element
>>>>>     3. throw an exception
>>>>>
>>>>> 2. is what C++'s map does, which is quite a mistake (albeit one that   could be ameliorated, given C++'s (current)
>>>>> greater
>>>>> expressiveness).
>>>>>
>>>>> 1. is a huge mistake, and I guess that's why no language/library (or  at  least none I'm aware of) has
>>>>> taken that option. (The exception of sorts is Ruby, which returns nil.)
>>>>>
>>>>> IMO, 3. is the only sane solution.
>>>>
>>>> I dislike 3 also, it would require code like:
>>>>
>>>> Field f;
>>>>
>>>> try {
>>>>   f = array["bob"];
>>>> } catch (UnknownKeyException e) {
>>>> }
>>>>
>>>> to get an item from an AA without a double lookup.
>>>
>>> Not so. I propose only a few hours ago that in should be redefined to be  a boolean, and we should add
>>
>> I saw that post, I proposed the same thing months ago, we're in agreeance  then.
>> Where does the exception come into it?
>
> The exception only occurs when using the subscript operator and the item does not exist

Ahh.. ok, if the 'contains' method is present, then I agree the exception is the way I'd go.

Regan