Calling superclass methods from implemented methods

[Matt Revelle]

I'm working on a patch to add support for calling the superclass'
implementation of a method when overriding a method in Clojure with
ns/:genclass. This looks like it requires a modification of the
InstanceMethodExpr class in clojure.lang.Compiler. The proposed
syntax would be: (. super/MethodFoo this args). One issue is that
using super/MethodFoo to refer to the superclass' method means that
(.super/MethodFoo this args) wouldn't work without more Parser changes.

I'm close to finishing this, but would like to get feedback before
spending more time. Thoughts?

-Matt

[Geoffrey Teale]

2008/12/8 Matt Revelle <mrev...@gmail.com>

Interesting.   I was actually looking for this functionality the other day.  The form you describe is almost exactly what I would expect.

I have found that the new (:gen-class) post AOT leads quite naturally to a OOP style of programming when interacting Qt-Jambi.   I'm torn as to whether this is a good or a bad thing (it may be neither, just a reality).   Realising this certainly made doing this kind of work more intuitive - and (super) would actually solve some problems for me.

--
Geoffrey Teale
Freelance Software and Technology Consultant
Munich, Germany

[Rich Hickey]

I would set aside the syntax and first describe the mechanism. Are you
going to generate a super-calling version of every method? Are you
going to try to emit code to generate invokespecial in the
implementing fn? The latter won't work as there is no type
relationship.

It might be easier to just enhance the :exposes to handle methods as
well, or add a :supers section.

Rich

[Matt Revelle]

The original plan was to use the super keyword to signal that
invokespecial should be used. Now that you mention the lack of type
relationship, that problem is obvious. I suppose adding a :supers is
what I'll do.

-Matt

[Matt Revelle]

The attached patch adds :super-methods option to generate-class as a
map, {local-name [name [param-types] return-type], ...}. The
mechanics work as Rich suggested in an earlier message, a method is
created that has the same type signature as the exposed method - it
loads the arguments, invokes the method, and returns the result.

An example can be viewed here:
http://gist.github.com/33787

I haven't done extensive testing, but seems to work.

-Matt

[Rich Hickey]

A couple of thoughts.

First - the local name must be a valid Java method name - you are
using dashes in your method names in the example code. Some VMs will
balk at this.

Second - it seems tedious and error-prone to have to specify the
signatures, which must match the method sigs.

Third, if a method is overloaded, multiple :super-methods entries must
be made.

Perhaps it would be better, and more consistent with :exposes, to take
a map of method_name -> exposing_method_name, and generate a set of
overloaded methods matching all overloads of the super method:

:exposes-methods {update super_update, render super_render}

This way people can't get the sigs wrong, and a single entry covers
all overloads.

Rich

[Matt Revelle]

On Dec 9, 2008, at 10:03 AM, Rich Hickey wrote:

>
>
>
> On Dec 9, 12:24 am, Matt Revelle <mreve...@gmail.com> wrote:
>> The attached patch adds :super-methods option to generate-class as a
>> map, {local-name [name [param-types] return-type], ...}. The
>> mechanics work as Rich suggested in an earlier message, a method is
>> created that has the same type signature as the exposed method - it
>> loads the arguments, invokes the method, and returns the result.
>>
>> An example can be viewed here:http://gist.github.com/33787
>>
>> I haven't done extensive testing, but seems to work.
>>
>
> A couple of thoughts.
>
> First - the local name must be a valid Java method name - you are
> using dashes in your method names in the example code. Some VMs will
> balk at this.
>
>
> Second - it seems tedious and error-prone to have to specify the
> signatures, which must match the method sigs.

I was going for explicitness, but agree it's both tedious and error-
prone. Fixed.

>
>
> Third, if a method is overloaded, multiple :super-methods entries must
> be made.
>
> Perhaps it would be better, and more consistent with :exposes, to take
> a map of method_name -> exposing_method_name, and generate a set of
> overloaded methods matching all overloads of the super method:
>
> :exposes-methods {update super_update, render super_render}
>
> This way people can't get the sigs wrong, and a single entry covers
> all overloads.

Thanks for the feedback, attached patch uses the syntax you suggested
and constructs all overloaded variants of the specified methods.

Updated usage example:
http://gist.github.com/33787

Take care!

-Matt

[Rich Hickey]

Patch applied (svn 1149) - thanks!

Rich