Inheriting static members

[Julien Wetterwald]

Hi all,

Is there a convenient way to simulate static member inheritance in Scala?

Cheers,
Julien

[Jon Pretty]

Hi Julien,

Julien Wetterwald wrote:
> Is there a convenient way to simulate static member inheritance in Scala?

I don't know of a 'direct' replacement, though I normally prefer the following refactoring.  It may
mean quite a significant change for your project, and might not be applicable, but it has (so far)
been a useful pattern.

Given a class X which we want to have a 'static' member m, make X an inner class of a new class Y
and make m a member of Y.  Any instance of Y (or if you were to make Y an object) now emulates X
having a static member.

We can then subclass Y, override m, and subclass X.

    class Y {
      def m = "m"
      class X {
        def x = "x"
      }
    }

    class Z extends Y {
      override def m = "m2"
      class X2 extends X {
        override def x = "x2"
      }
    }

Typically this means that much of your code (at least that which accesses m) will need to go within
Y (or Z).  This is best done by mixing in traits, e.g.:

    trait W requires Y {
      def q = "q"+m
    }

and then we mix it in:

    class Z
      extends Y
      with W
    {
      ...
    }

Does anyone know if this pattern has a name?

Jon

--
Jon Pretty | Sygneca Ltd.

[Jon Pretty]

Hi Martin,

martin odersky wrote:
> I don't know of a name, but it seems to be the pattern described in
> the Scalable Component Abstractions paper. It would probably be a good
> idea to find a name for this.

I hadn't seen that paper before; now I've got some bedtime reading tonight...

Would you say that it counts as two patterns (mixins for modularity plus inner classes for
abstraction), or just one?

I'll start thinking...

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.

[Jon Pretty]

Jon Pretty wrote:
> I'll start thinking...

Misnaming entities such as design patterns can have devastating effects lasting several years, so
I'm wary of choosing something which ends up being misleading or confusing.

My suggestion is to call this pattern the 'Cake Pattern'.

The rationale, beyond my appreciation of cake, is that a cake is made of a number of layers
(separated by jam), and can be sliced.

The layers represent the different levels of inner class nesting.  It is conceivable that you would
reach the bottom layer by working your way down from the top.

The slices represent the modularization of the project, where each slice may crosscut several
layers, i.e. a two layer cake cut into two slices might be equivalent to:

   trait A {
     trait B {}
   }

   trait C extends A {
     trait D extends B {}
   }

What do other people think?

Jon

--
Jon Pretty | Sygneca Ltd.

[Jon Pretty]

Jon Pretty wrote:

> i.e. a two layer cake cut into two slices
> might be equivalent to:
>
>   trait A {
>     trait B {}
>   }
>
>   trait C extends A {
>     trait D extends B {}
>   }

Correction:

    trait C requires A {
      trait D requires B {}
    }

--
Jon Pretty | Sygneca Ltd.

[Julien Wetterwald]

Thanks Jon, the 'Cake Pattern' is perfectly suited for what I am trying
to do.

Cheers,
Julien

[martin odersky-2]

> Thanks Jon, the 'Cake Pattern' is perfectly suited for what I am trying
> to do.
>
... and I really like the name. -- Martin

[Adriaan Moors-2]

On 24 Apr 2007, at 16:15, martin odersky wrote:

>> Thanks Jon, the 'Cake Pattern' is perfectly suited for what I am  
>> trying
>> to do.
>>
> ... and I really like the name. -- Martin
"Scala: having your Cake and eating it too" ;-)

adriaan

[Jon Pretty]

Adriaan Moors wrote:
>> ... and I really like the name. -- Martin
> "Scala: having your Cake and eating it too" ;-)

Cake it is, then.  I've updated the Scala Wiki.

--
Jon Pretty | Sygneca Ltd.