[Laszlo-dev] SWF9 - overrides within mixins

[P T Withington]

Since a mixin is an "interface with implementation", it makes sense to  
me that the implementation part of the mixin should obey the same  
rules that a subclass would have to obey.  So, if the mixin is  
overriding, it should declare override.  If the mixin has a public  
method, it should declare it public.

When your compiler splits the mixin into an interface and an  
implementation (interstitial class), the only signatures that should  
appear in the interface are the public parts of the mixin, right?  It  
would not make sense to have an interface declare a method that is not  
public.  At least that's the way I interpret your results.  An  
interface is a contract about an API, to have part of the API be  
inaccessible just wouldn't be useful.

Similarly, I expect that you probably _can_ define an interface to be  
in a namespace, but then all the methods that it specifies would have  
to be in the same namespace too, so that if you have access to the  
namespace you have access to the API, but you either get the whole API  
or nothing.

To answer your specific question:

> Should we require 'public' on the mixin?  or is it optional?

In a mixin, 'public' means that it is part of the mixin interface  
(part of the API contract defined by the mixin), whereas non-public  
(default) means that it is only part of the mixin implementation.  It  
may support the implementation of the API, but it is not part of the  
API.

_Probably_ we should also allow a mixin to declare just an API  
signature also, which would be a way of indicating a "required method"  
of any subclass that mixes it in.  Unfortunately, from your  
experiments, it appears that such a required method would have to be  
public, which is often not what you want (since a required method is  
meant to be a constraint on the sub or concrete class implementation,  
not on its API).

On 2008-02-07, at 15:20 EST, Donald Anderson wrote:

> In the classic 'Sundae extends Vanilla with Banana' example,
> all of the classes define function 'test'.  Just focusing on this  
> part,
> I was a little confounded by the need for override and public  
> keywords.
> What follows is a recipe that works, and it does make sense.
> 'public' and 'override' must appear exactly as indicated:
>
>  class Vanilla {
>    public function test () { return "vanilla"; }
>  }
>
>  interface Banana {
>     function test () ;
>  }
>
>  class Banana$Vanilla extends Vanilla implements Banana {
>    public override function test () { return "banana"; }
>  }
>
>  class Sundae extends Banana$Vanilla {
>    public override function test () { return "sundae"); }
>  }
>
> In Banana$Vanilla:test, the 'public' is needed satisfy
> the 'implements Banana'.  The 'override' is needed since
> test is also defined in Vanilla.
>
> In Sundae:test, 'override' is needed because test is defined in
> superclasses.  'public' is needed to match Banana$Vanilla.
>
> In Vanilla:test, the 'public' is needed to match what is being
> overridden in Banana$Vanilla.
>
> So back up to what the original source must look like:
>
> class Vanilla {
>    public function test () { return "vanilla"; }
>  }
>
>  mixin Banana {
>    /*public?*/ override function test () { return "banana"; }
>  }
>
>  class Sundae with Banana {
>    public override function test () { return "sundae"); }
>  }
>
> Should we require 'public' on the mixin?  or is it optional?
> (It actually doesn't matter much to me -- I think I always emit
> public in the class, and no public in the interface).
> Obviously if you know that the ultimate superclass has test(),
> then the mixin should declare it override.  Is this something
> we'll know in practice?   In theory this could be detected
> for the classes we see in the parse, but it's a bigger deal
> if the method being overridden is in a library (eventually).
>
> Also, I was wondering how namespaces work in this.
> From some quick experiments, it looks like namespaces
> are not allowed on interface methods,
>   interface Banana {
>    //   ns1 function another();   // XXX compiler error
>       function another();
>   }
> nor by using a namespace name can you fulfill your implementation:
>   class Banana$Vanilla extends Vanilla implements Banana {
>       ns1 function another();    // XXX error - Banana not  
> implemented.
>   }
>
> - Don
>
> --
>
> Don Anderson
> Java/C/C++, Berkeley DB, systems consultant
>
> voice: 617-547-7881
> email: dda at ddanderson.com
> www: http://www.ddanderson.com
>
>
>
>