Re: Covariant Return Types

> I understand that both are overloaded. My point is that it is confusing to
> borrow the Java syntax but with different semantics. 

OK, I get your point.

> Why did you choose to make overriding explicit and overloading implicit? I think
>  I am more likely to inadvertently overload a method when I meant to override
> it, than I am to inadvertently override a method when meaning to overload it,
> because I am used to programming in Java. Maybe both should be explicit?

There is a fundamental reason to make overriding explicit and overloading implicit.

With overriding, you specialize an existing method, of which you need to know 
the contract (type, requires and ensures clauses). The overriding implementation 
is tightly coupled to the method declaration, you need to know its existence.

On the other hand, overloading can rigthfully happen "by accident". Two methods 
have the same name, and might have completely unrelated types. The names might 
even be homonyms.

So far, I think the distinction is clear, and there should be no confusion.

Now, confusion might arise if you use overloading with methods whose types 
overlap. In particular, I think we might simply forbid an overloaded method 
which has more specific argument types than another known method: this could be 
handled by overriding instead (once we can specialize the return type). This 
would solve the issue you raised, I think.

>>Pros for implicitness:
>>  - lighter syntax
>>  - robust to the presence or absence of the overriden method
>>  - similar to Java
>>Cons for implicitness:
>>  - if you make a typo in the method name, there will be no static 
>>error. your implementation will just silently be ignored, which can be 
>>pretty hard to debug
>>  - the intention to override a method is not visible from the source
>>
>>The arguments for and against explicitness are exactly the opposite.
> 
> 
> I suppose you can use emperical evidence from Java to measure the importance of
> the first con. I know I have had that problem before but it usually doesn't take
> long to find it in Java. 

Do others have opinions/experiences about this?

> As an alternative, imagine a "method" keyword that must
> be prefixed to a method declaration. Then you have:

Yes, that's true: instead of marking overriding implementations, you can mark 
declarations. It works, the point being that implementation and declaration 
should look different.

An advantage of marking implementations is that you only need to do it when the 
return type is specialized (otherwise the implementation already looks 
different, like they do in current Nice), which I think is a rather rare case. 
So globally you have much less keywords in the program.

Of course, at this stage this is a matter of taste.

>><A T> T self(T);
>>
>>self(#A this) { ... }
>>
>>self(#B this) { ... }
>>
>>
>>I see this corresponds to self3 in your example, but maybe you had 
>>trouble specializing it? The #B part says "when the argument is exactly 
>>of class B, not merely one of its subclasses, use this implementation)".
> 
> 
> But then I may want to to write:
> 
>      <A T> T self(T);
>              self(#A this) { ... }
>      <B T> B self(#T this) { ... }
> 
> That is, I may want to specialize =self= for class B without having to
> specialize it for every one of its subclasses, while only guarenteeing that the
> result has type B (not T). 

That would be unsafe. Consider the following example:

package a;

<A T> T self(T);
self(#A this) { ... }

<A T> T foo(T x) = self(x);
// This is obviously well typed

package b;

<B T> B self(#T this) { ... }

class C extends B {}

void main() {
   C C = foo(new C());
   // This is well typed
   // But foo calls self, and since a C is a B, the specialized implementation
   // is called and returns a B. Boom!
}

Basically, your change of the return type was not covariant, so it cannot be 
accepted.

Daniel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn