bugKawa - Bugs: bug #16515, Overriding a method with...

 
 

bug #16515: Overriding a method with incompatible return types should result in compile-time error

Submitter:  Dean Ferreyra <dferreyra>
Submitted:  Wed 03 May 2006 10:01:02 PM UTC
   
 
Category:  Type declaration and inference Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

  Spam posted by anonymous
Tue 17 Mar 2009 04:54:36 PM UTC, comment #2: 

We now get a warning:

/tmp/foo.scm:2:3: warning - cannot convert literal (of type java.lang.String) to long

But if you add an explicit return type:

(define-simple-class <MySchemeClass> (<java.util.Date>)
  ((getTime) :: String
   "a string"))

you silently get an invalid override.

Now that Java 5 supports co-variant return types we should support those - and check when the return type is incompatible.

Per Bothner <bothner>
Group administrator
Tue 17 Mar 2009 09:47:33 AM UTC, comment #1: 

is this bug fixed
<a href='http://askmeflash.com'>http://askmeflash.com</a>

Anonymous
Wed 03 May 2006 10:01:02 PM UTC, original submission:  

Here's a simple example from Chris Dean:

--------------------------------------------------
This Java class will not compile because the return value for getTime() is of the wrong type:

  public class MyJavaClass extends java.util.Date {
        public String getTime() {
            return( "a string" );
        }
    }

  MyJavaClass.java:2: getTime() in MyJavaClass cannot override getTime() in java.util.Date; attempting to use incompatible return type
    found : java.lang.String
    required: long
        public String getTime() {
                    ^
    1 error

However, this Kawa code will compile and produce the wrong class:

  (define-simple-class <MySchemeClass> (<java.util.Date>)
    ((getTime)
     "a string"))
--------------------------------------------------

Attached is a more complicated example based on a problem encountered by our developers.  The part that's at first surprising is that which method gets called depends on how the function being returned has been defined (see base-lambda vs. base-fn).

I think it boils down to the fact that in the <A>/<B> example, the signatures of A.m0 and B.m0 vary in return type.  The results mentioned in the comments only apply to compiled code.

Maybe there's another problem being exposed by this example, but I think if the compiler issued an error when it encounters an override with incompatible return types, it would help narrow down these problems much more quickly.

This isn't a show-stopper.  It crops up every once in a while and is difficult to debug, and it would be nice if some kind of fix worked its way into Kawa.

Dean Ferreyra <dferreyra>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #9886:  override.scm added by dferreyra (2KiB - application/octet-stream - The more complicated example)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bothner (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2006-05-03 dferreyra Attached File- Added override.scm, #9886

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code