[Caml-list] Delegation based OO

[Caml-list] Delegation based OO

[Alex Baretta]

Away from politics and back to the ordinary stuff...

Presently Ocaml supports the following OO paradigm:

class does_something = object .. end

class does_more = object
   inherit does_something
   ...
end

This allows us to extend the functionality of CLASSES. What about 
extending the functionality of objects?

class *type* does_something = object ... end

class does_more (an_object:#does_something) = object
   delegates an_object
   ...
end

This is very important to me because in my code I often use the concept 
of proxy-object.

let prototype = match whatever with
   | ... as first_case -> new does_it_the_first_way
   | ... as second_case -> new does_it_the_second_way
   | ... as third_case -> new does_it_the_third_way

class does_more prototype = object
   method one = prototype # one
   method two = protype # two
   ...
end

This is really a pain. I would expect delegation to be supported in the 
coolest OO language under the sun ;)

O great Caml breeders, what do you say to this?

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Yamagata Yoriyuki]

From: Alex Baretta <alex@baretta.com>
Subject: [Caml-list] Delegation based OO
Date: Mon, 22 Mar 2004 11:18:05 +0100

> This is really a pain. I would expect delegation to be supported in the 
> coolest OO language under the sun ;)

As far as I know, type theory for object-based OO is still
on-going research topic.

In your example,

class *type* does_something = object ... end

class does_more (an_object:#does_something) = object
   delegates an_object
   ...
end

"an_object" may have a method, say, "an_object#foo : int".
"does_more" could overwrite the method, and define "does_more#foo :
float".  Now, what type should "self#pooh" have in the definition of
an_object?

But you know something I do not aware?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Kenneth Knowles]

> class *type* does_something = object ... end
> 
> class does_more (an_object:#does_something) = object
>    delegates an_object
>    ...
> end
> 
> "an_object" may have a method, say, "an_object#foo : int".
> "does_more" could overwrite the method, and define "does_more#foo :
> float".  Now, what type should "self#pooh" have in the definition of
> an_object?

This is a type error, just as if you override a class method with one of a
different type:

# class x = object method y = 3 end;;
class x : object method y : int end
# class y = object inherit x method y = 4 end;;
class y : object method y : int end
# class z = object inherit x method y = "hello" end;;
This expression has type string but is here used with type int

The same strictness could be applied to delegation.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Jacques Garrigue]

From: Alex Baretta <alex@baretta.com>

> Away from politics and back to the ordinary stuff...
[...]
> This allows us to extend the functionality of CLASSES. What about 
> extending the functionality of objects?
> 
> class *type* does_something = object ... end
> 
> class does_more (an_object:#does_something) = object
>    delegates an_object
>    ...
> end
> 
> This is very important to me because in my code I often use the concept 
> of proxy-object.

Interesting idea. It would be even more useful now that one can define
immediate objects (without explicitely defining a class).
And recent changes on the implementation make direct delegation
very cheap in terms of code size.
Note however that one needs to know more clearly which methods are to
be delegated, so I would rather favor a notation like:

 class does_more an_object = object
    delegate does_something to an_object
    ...
 end

which clearly would get the same type.
As always the main trouble is that it requires a new keyword...

This is worth considering.

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Alex Baretta]

Jacques Garrigue wrote:

> 
> Interesting idea. It would be even more useful now that one can define
> immediate objects (without explicitely defining a class).
> And recent changes on the implementation make direct delegation
> very cheap in terms of code size.
> Note however that one needs to know more clearly which methods are to
> be delegated, so I would rather favor a notation like:
> 
>  class does_more an_object = object
>     delegate does_something to an_object
>     ...
>  end

Ah! I see your point. Why not? Of course, delegating a class signature 
to an object allows you to define explicitely the type components which 
the type of does_more imports from the type of an_object. This would 
probably help the type checker a lot at giving sensible error messages.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Correnson Loïc]

This is a very interesting way of OO-programming.
More over, it allows to fullly benefit from multi-inheritance:

Suppose we have:
class type a = object ... end
class type b = object ... end

Then:
class a_and_b = object
    delegates [classtype to] a ;
    delegates [classtype to] b ;
end

I mainly found the requirement for such a delegation mechanism while looking
at GUI system, where classes have in general a *lot* of methods that must be
delgated by hand.

>From the compiler point of view, notice that such a delegation mechanism
would be  concistent with the one already existing for modules (and
functors) thanks to the "include" statement:

module type A = sig ... end
module type B = sig ... end
module A_and_B(mA : A)(mB : B) = struct
   include mA [ : A] ;
   include mB [ : B] ;
end

>From an academic point of view, and looking for a beautiful symetry between
objects and modules, such an delegation-based OO system would be a nice
construction.

    Loic Correnson.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Stefano Zacchiroli]

On Tue, Mar 23, 2004 at 10:14:02AM +0900, Jacques Garrigue wrote:
> Note however that one needs to know more clearly which methods are to
> be delegated, so I would rather favor a notation like:
> 
>  class does_more an_object = object
>     delegate does_something to an_object
>     ...
>  end

Isn't enough to have a (closed) object type annotation for "an_object"?
In this way you would now exactly the signature of the object to which
you want to delegate without having to enumerate all of them.

I find Alex idea really cool, delegation is a widely used technique in
OO programming but at the same time is painful to use because you have
to write the pattern:

  method foo = delegate#foo
  method bar = delegate#bar
  ...

Having to write

  delegate foo to delegate
  delegate bar to delegate
  ...

is not a big improvement, whereas writing

  class type delegate_type =
    object
      method foo: ...
      method bar: ...
      ...
    end

  delegate delegate_type to an_object

would really be an improvement.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Alex Baretta]

Stefano Zacchiroli wrote:

> Having to write
> 
>   delegate foo to delegate
>   delegate bar to delegate
>   ...
> 
> is not a big improvement, whereas writing


You missed the point, Zack.

   delegate class_type_foo to object_implementing_class_type_foo

This delegates all methods defined by class_type_foo to the prototype 
object.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Jacques Garrigue]

From: Stefano Zacchiroli <zack@bononia.it>
> On Tue, Mar 23, 2004 at 10:14:02AM +0900, Jacques Garrigue wrote:
> > Note however that one needs to know more clearly which methods are to
> > be delegated, so I would rather favor a notation like:
> > 
> >  class does_more an_object = object
> >     delegate does_something to an_object
> >     ...
> >  end
> 
> Isn't enough to have a (closed) object type annotation for "an_object"?
> In this way you would now exactly the signature of the object to which
> you want to delegate without having to enumerate all of them.

Looks like there is a misunderstanding here: in Alex's example,
does_something was an object type. So yes, the above amounts to an
object type annotation, and declares simultaneously all the methods
included in the type.
The idea is to have something similar to variant dispatch
   function #super_a as x -> ... | #super_b as x -> ... | #super_c as x -> ...

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Stefano Zacchiroli]

On Tue, Mar 23, 2004 at 06:44:19PM +0900, Jacques Garrigue wrote:
> Looks like there is a misunderstanding here: in Alex's example,
> does_something was an object type. So yes, the above amounts to an
> object type annotation, and declares simultaneously all the methods

Ok, this is indeed what I was looking for.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Yamagata Yoriyuki]

From: Kenneth Knowles <kknowles@berkeley.edu>
Subject: Re: [Caml-list] Delegation based OO
Date: Mon, 22 Mar 2004 16:29:26 -0800

> This is a type error, just as if you override a class method with one of a
> different type:
> 
> # class x = object method y = 3 end;;
> class x : object method y : int end
> # class y = object inherit x method y = 4 end;;
> class y : object method y : int end
> # class z = object inherit x method y = "hello" end;;
> This expression has type string but is here used with type int
> 
> The same strictness could be applied to delegation.

There is a difference.  You cannot hide the method "y" in the class
definition "x". An object can be coerced to a super type, so that it's
type would forget about the method "y", then you override it...

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Kenneth Knowles]

On Wed, Mar 24, 2004 at 08:43:00AM +0900, Yamagata Yoriyuki wrote:
> There is a difference.  You cannot hide the method "y" in the class
> definition "x". An object can be coerced to a super type, so that it's
> type would forget about the method "y", then you override it...
> 
> --
> Yamagata Yoriyuki

Good point, I think.
Let's see if I understand; I think you mean the following imaginary situation:

# class type delegate :
  object
    method b : int
  end;;

...

# class x =
  object(self)
    method a = 3
    method b = self # a
  end;;

...

# class y (del : delegate) =
  object
    delegate del

    method a = "hello"
  end;;

...

# let foo = new x;;
val foo : <a : int; b : int>

# let bar = new y (x :> delegate)
val bar : <a : string; b : int>

This is solved by treating delegation as object composition, rather than
inheritance, making overriding irrelevant.  The original methods of "del" all
point to the same "self" object.

This also solves the use of delegating only a subset of methods, since only the
methods of the statically determined (or specified) type of "del" are delegated,
minus the methods defined by "x."

I'm not advocating adding this to the language, but it does seem pretty
straightforward.

Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Alex Baretta]

Kenneth Knowles wrote:
> On Wed, Mar 24, 2004 at 08:43:00AM +0900, Yamagata Yoriyuki wrote:

> Good point, I think.
> Let's see if I understand; I think you mean the following imaginary situation:
> 
> # class type delegate :
>   object
>     method b : int
>   end;;
> 
> # class x =
>   object(self)
>     method a = 3
>     method b = self # a
>   end;;
> # class y (del : delegate) =
>   object
>     delegate del
> 
>     method a = "hello"
>   end;;
> 

Delegation is no relative of inheritance. Inheritance is a syntactic 
property (essentially classes inherit code), whereas delegation is a 
semantic property: once one method is delegated by a proxy object to an 
executor object, the the visibility of the proxy is lost. The method is 
executed as if it were invoked directly on the executor.

As far as I'm concerned delegation serves specifically to implement 
efficiently (loc-wise) the proxy object pattern. Consider a DB access 
library where you define classes to access different DBMSs. The proxy 
object is backend neutral and dispatches depending on a configuration 
string or equivalent data structure. This can be done now, but each 
method in the proxy must be delegated explicitly to the backend object. 
Delegation passes control from the proxy to the backend in one line of code.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Yamagata Yoriyuki]

From: Alex Baretta <alex@baretta.com>
Subject: Re: [Caml-list] Delegation based OO
Date: Wed, 24 Mar 2004 11:43:48 +0100

> Delegation is no relative of inheritance. Inheritance is a syntactic 
> property (essentially classes inherit code), whereas delegation is a 
> semantic property: once one method is delegated by a proxy object to an 
> executor object, the the visibility of the proxy is lost. The method is 
> executed as if it were invoked directly on the executor.

There is a certain approach (object-based OO) which makes inheritance
to be a relation between objects (and get rid of the concept of class
altogether).  In this approach, we can add, and modify mothods in
objects in run time.  I confuse this with Alex proposal.

--
Yamagata Yoriyuki

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Alex Baretta]

Yamagata Yoriyuki wrote:
> 
>>Delegation is no relative of inheritance. Inheritance is a syntactic 
>>property (essentially classes inherit code), whereas delegation is a 
>>semantic property: once one method is delegated by a proxy object to an 
>>executor object, the the visibility of the proxy is lost. The method is 
>>executed as if it were invoked directly on the executor.
> 
> 
> There is a certain approach (object-based OO) which makes inheritance
> to be a relation between objects (and get rid of the concept of class
> altogether).  In this approach, we can add, and modify mothods in
> objects in run time.  I confuse this with Alex proposal.


"Object based object orientation" is simply horrible English. 
"Delegation based object orientation" is both more expressive of what 
really goes on behind the scenes and more appropriate from a linguistic 
standpoint.

What you have in mind is JavaScript, a delegation based 
object-functional language with dynamic typing. What Jacques and I are 
discussing is a class-and-delegation based object-functional paradigm, 
an extension to ocaml's present class based object-functional approach.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Delegation based OO

[Kenneth Knowles]

On Wed, Mar 24, 2004 at 11:43:48AM +0100, Alex Baretta wrote:
> Delegation is no relative of inheritance. Inheritance is a syntactic 
> property (essentially classes inherit code), whereas delegation is a 
> semantic property: once one method is delegated by a proxy object to an 
> executor object, the the visibility of the proxy is lost. The method is 
> executed as if it were invoked directly on the executor.

I disagree with the "syntactic" vs "semantic" distinction, but the message that
they are different animals is exactly my point as well; I contrast the two
because previous messages had compared them (mention of "overriding").  The
debate seems to really be about which methods should be delegated, which is
easily regulated by typing.

"delegate x to y" could be "delegate (y :> x)" so you avoid yet another language
construct.  Most of the time I would expect this to actually occur like so:

class foo (del : delegate_class_type) =
object
	delegate del (* Don't need any type annotation or "to" keyword here *)
end


Kenn

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners