You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2013/06/24 06:29:56 UTC

[lucy-dev] Interfaces / mixins

On Sat, Jun 22, 2013 at 8:28 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> But there are some useful features from languages with static OO like Java
> that could be implemented without impact on performance. Class methods
> should be an easy one, for example. Interfaces would be useful, too, but
> more involved.

I see you've now opened an issue about interfaces.

    https://issues.apache.org/jira/browse/LUCY-258

I agree that those would be a very useful feature.  For instance, it would
allow us to clean up the mess I made of Freezer.c once we removed Serialize()
and Deserialize() from Clownfish::Obj.

One limitation of "Java-style interfaces" is that all interface methods must
be abstract.  I've never understood the rationale for that.

Is there any reason that we couldn't allow default implementations?  Consider
the Ruby mixin Comparable:

    http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html#S2

    The Comparable mixin can be used to add the comparison operators (<, <=,
    ==, >=, and >), as well as the method between?, to a class. For this to
    work, Comparable assumes that any class that uses it defines the operator
    <=>. So, as a class writer, you define the one method, <=>, include
    Comparable, and get six comparison functions for free.

Comparable provides one abstract method and six default implementations
defined in terms of that abstract method.  Subclasses which implement
Comparable are welcome to override the default implementations for the sake of
efficiency, but often that won't be necessary.

Ruby is a little more flexible in that mixins have access to instance
variables, whereas our interface/mixin methods would not -- they would only be
allowed to access other methods defined in the same interface.  But it still
seems worthwhile to allow non-abstract methods.

> Also, every Clownfish feature must be mapped to the host language. This
> automatically rules out anything too exotic.

For Perl at least, I imagine we'd use multiple inheritance.

    package MyObj;
    use base qw( Clownfish::Obj Clownfish::Comparable );

Marvin Humphrey

Re: [lucy-dev] Interfaces / mixins

Posted by Nick Wellnhofer <we...@aevum.de>.
On Jun 24, 2013, at 06:29 , Marvin Humphrey <ma...@rectangular.com> wrote:

> I see you've now opened an issue about interfaces.
> 
>    https://issues.apache.org/jira/browse/LUCY-258
> 
> I agree that those would be a very useful feature.  For instance, it would
> allow us to clean up the mess I made of Freezer.c once we removed Serialize()
> and Deserialize() from Clownfish::Obj.
> 
> One limitation of "Java-style interfaces" is that all interface methods must
> be abstract.  I've never understood the rationale for that.
> 
> Is there any reason that we couldn't allow default implementations?  Consider
> the Ruby mixin Comparable:
> 
>    http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html#S2
> 
>    The Comparable mixin can be used to add the comparison operators (<, <=,
>    ==, >=, and >), as well as the method between?, to a class. For this to
>    work, Comparable assumes that any class that uses it defines the operator
>    <=>. So, as a class writer, you define the one method, <=>, include
>    Comparable, and get six comparison functions for free.
> 
> Comparable provides one abstract method and six default implementations
> defined in terms of that abstract method.  Subclasses which implement
> Comparable are welcome to override the default implementations for the sake of
> efficiency, but often that won't be necessary.
> 
> Ruby is a little more flexible in that mixins have access to instance
> variables, whereas our interface/mixin methods would not -- they would only be
> allowed to access other methods defined in the same interface.  But it still
> seems worthwhile to allow non-abstract methods.

Makes total sense. The default implementations would simply work on Clownfish::Obj objects.

> For Perl at least, I imagine we'd use multiple inheritance.
> 
>    package MyObj;
>    use base qw( Clownfish::Obj Clownfish::Comparable );

Yes, for dynamically typed languages which lookup methods by name, we don't even need an interface type with extra bindings for the interface methods. For Perl, an interface could be an empty class that's only used for ISA checks. The interface methods would still be correctly dispatched via the implementing class.

Nick