Extending using Wrapping

Ever had a problem, not being able to add more functionality to an existing class? Some languages seem to support adding functionality to an existing class but it does make it less secure and leaves a lot of dangers of maluse.

A solution could be to create a new class which inherits the original class although it can only be instanciated using a cast from an instance of the original class or instanciating providing the original instance. Also it won’t be able to override anything otherwise it couldn’t act as its base object.

A possible implementation of this idea could be:

wrapper Int_IsOdd : int {
  public bool IsOdd() {
    return this % 2;
  }
}

And it could be used in several ways:

int myInt = 100;
print ((Int_IsOdd)myInt).IsOdd();
print myInt.IsOdd();
print new Int_IsOdd(myInt).IsOdd();

The first way would be the easiest for both a reader which isn’t familiar with the extension and for the compiler to guess errors. The second would be neat to use but it would be confusing for people that cannot access the rest of the source or do not know what function is meant. The third way would be very compatible.

I wondered by myself whether normal inheritance could provide this functionality.. and it does. The only problem is that polyforism only works up and not down as the wrapper requires. (when you got a class a and b inherits of a, you can with inheritance treat an instance of b as a but you cant treat an instance of a as b which is required for the wrapper)

Also a wrapper would be more cached and not really a new instance as suggested by the way it seems to work and can already be slightly implemented in existing languages.

Maybe it’ll be put in paradox.

update – I talked with Kaja, and it will most likely be a feature of paradox

4 thoughts on “Extending using Wrapping”

  1. I really don’t see the difference between normal inheritance and your wrapper. Could you explain it once more? Inheritance working up and not down doesn’t make sense to me.

  2. When you got object a and b where b is an inheritance of a you can treat an instance of b as a. But you can’t treat an instance of a as b.

    edited post… guess i was to vague

    Also the way it would be implemented would be totaly different.. more like a wrapper instead of its own instance i guess

  3. I suppose you would only be able to add more methods/functions, basicly extending objects.

    Have you thought about downcasting objects where the downcast actually has more properties? I realize that this might be slightly difficult and would probably require specific invariants to keep it all going.

    To illustrate, you would have a object of say type fish. which just has basic properties and methods of a fish. Now you could downcast (upgrade it? maybe we should call it ‘evolve’) it to a cod fish where all sorts of extra properties and methods are defined. The codfish object would be initialised with the fish object.

    Maybe it is better illustrated with shapes. Say you have a object of type ‘shape’ which is a high abstract type object. Now you really need a cube, could you ‘evolve’ the shape into a ‘cube’. Depending on the properties of the shape, the answer might be yes or no. Or you might have to change the shape in order to ‘evolve’ it into a cube.

  4. When letting it evolve you would inherit it… a wrapper merely is a layer on top to handle…

    lets say to got a computer object.. then you matbe could add a new keyboard with a lot of new shortcuts but without changing something to the computer.. in other words you will never ovveride anything.. you just extend..

    For it basicly can’t override anything it basicly creates a different new interface to interact with the object where it also is able to get to the protected members, it is basicly a wrapper :p.

Leave a Reply

Your email address will not be published. Required fields are marked *