[Caml-list] Five Questions about Objects

[Caml-list] Five Questions about Objects

[Oleg]

Hi

A few questions on objects:

1) Why does the following code define a polymorphic class

 class point a b = 
    object 
      val x = a
      val y = b
    end;;

but adding "method get () = (x, y)" results in type errors only resolvable by 
specifying types with "class ['a, 'b] point (a:'a) (b:'b)" ? Why doesn't 

 class point a b = 
    object 
      val x = a
      val y = b
      method get () = (x, y)
    end;;

give me a polymorphic class?

2) What is the point of "class" and "new" keywords? How are they better than 
"let" ? E.g.

let point a b = 
  object
    val x = a
    val y = b
    method get () = (x, y)
  end;;

let my_point = point 3 7;; 
let many_float_points = Array.make 100 (point 4.0 3.0);;
?

3) Is it possible to access object datafields directly or only through 
methods?

4) Can I construct an object that the following function f would accept?
# let f a = a#m1 (); a#b#m2 ();;
val f : < b : < m2 : unit -> 'a; .. >; m1 : unit -> 'b; .. > -> 'a = <fun>

I tried the obvious (to me) and it doesn't work. What is the precedence and 
associativity of #?

5) What is the current state of marshalling objects? Is Jacques's patch going 
to be used in the upcoming O'Caml version or is it too untested? 

Thanks
Oleg
-------------------
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] Five Questions about Objects

[YAMAGATA yoriyuki]

From: Oleg <oleg_inconnu@myrealbox.com>
Subject: [Caml-list] Five Questions about Objects
Date: Sat, 13 Jul 2002 09:42:47 -0400

> let point a b = 
>   object
>     val x = a
>     val y = b
>     method get () = (x, y)
>   end;;

I think You can't do like this.  object ... end is a part of a class
definition, and not an ordinary expression.

However, I wonder why a class is necessary in the first place.  I'm
not familiar with the theory of OOP, but I feel like direct creation
of objects is possible in functional languages.  It simplifies the
syntax, fits better the concept of functional programming, (I mean
the slogan that everything is an expression.) and more powerful.  Ok,
maybe it does not have much advantage over current approach, but if
both can do the same thing, why not use the simpler one?

> 4) Can I construct an object that the following function f would accept?
> # let f a = a#m1 (); a#b#m2 ();;
> val f : < b : < m2 : unit -> 'a; .. >; m1 : unit -> 'b; .. > -> 'a = <fun>

# class ['b] b (v:'b) = object method m2 () = v end;;
class ['a] b : 'a -> object method m2 : unit -> 'a end
# class ['a, 'c] a (v1: 'c) (v2:'a b) = 
object method m1 () = v1 method b = v2 end;;
class ['a, 'b] a :
  'b -> 'a b -> object method b : 'a b method m1 : unit -> 'b end
# f (new a 0 (new b 0));;
- : int = 0

--
Yamagata Yoriyuki
http://www.mars.sphere.ne.jp/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] Five Questions about Objects

[Brian Smith]

YAMAGATA yoriyuki wrote:
> From: Oleg <oleg_inconnu@myrealbox.com>
> Subject: [Caml-list] Five Questions about Objects
> Date: Sat, 13 Jul 2002 09:42:47 -0400
> 
> 
>>let point a b = 
>>  object
>>    val x = a
>>    val y = b
>>    method get () = (x, y)
>>  end;;
>>
> 
> I think You can't do like this.  object ... end is a part of a class
> definition, and not an ordinary expression.
> 
> However, I wonder why a class is necessary in the first place.  I'm
> not familiar with the theory of OOP, but I feel like direct creation
> of objects is possible in functional languages.

I think that the "class" and "class type" constructs are useful when 
expressing the relationship between types/classes. For example, "let 
point a b..." defines a function that creates an object. But, what does 
(x :> point) mean when point is a function instead of a class type? If 
anything, I would thing that (f :> g) would mean that the return type 
and parameter types of f follow the covariant/contravariant rules for 
methods. Similarly, what would the #point construct mean?

Also, class types are types, and classes define implicit types, so I 
think that the class syntax should be close to the syntax for defining 
other kinds of types, instead of the syntax for defining functions.

- Brian
-------------------
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] Five Questions about Objects

[Jacques Garrigue]

From: Oleg <oleg_inconnu@myrealbox.com>
> A few questions on objects:
> 
> 1) Why does the following code define a polymorphic class
> 
>  class point a b = 
>     object 
>       val x = a
>       val y = b
>     end;;

It is not a "polymorphic class", but a class containing polymorphic
variables. You have no way to access them from outside the class.

> but adding "method get () = (x, y)" results in type errors only
> resolvable by  specifying types with "class ['a, 'b] point (a:'a)
> (b:'b)" ? Why doesn't
> 
>  class point a b = 
>     object 
>       val x = a
>       val y = b
>       method get () = (x, y)
>     end;;
> 
> give me a polymorphic class?

A class definition defines four things
* a class value, to build objects and inherit from
* a class type, to use in interfaces
* an object type, to abbreviate the < m1: t1; ...; mn: tn > notation
* an object subtype #c, to abbreviate < m1: t1; ...; mn: tn; .. >

The above would be ok for the class value alone, but in order to
define the class and object types, you need to make explicit the type
parameters. This is the goal of the class ['a] c ... notation.
Otherwise you might end up with type definition different from what
you were expecting (two many type variables, different parameter order...)

I sometimes wonder if it would not be possible to allow defining the
class alone, without defining types, but this might be more confusing
than useful.

> 2) What is the point of "class" and "new" keywords? How are they better than 
> "let" ? E.g.
> 
> let point a b = 
>   object
>     val x = a
>     val y = b
>     method get () = (x, y)
>   end;;

See the above explanation. A class definition does not define only a value.

> let my_point = point 3 7;; 

No very deep reason for new, yet there are some semantic differences.
For instance, if your class takes no arguments but contains mutable
fields, each call to new creates a fresh object.
That is,
     let c = new c in c, c
is not equivalent to
     new c, new c

> 3) Is it possible to access object datafields directly or only through 
> methods?

Only through methods.
Otherwise variables should appear in the object type.

> 4) Can I construct an object that the following function f would accept?
> # let f a = a#m1 (); a#b#m2 ();;
> val f : < b : < m2 : unit -> 'a; .. >; m1 : unit -> 'b; .. > -> 'a = <fun>

Yoriyuki Yamagata already answered.

The LablGTK is full of such methods calls.

> 5) What is the current state of marshalling objects? Is Jacques's
> patch going  to be used in the upcoming O'Caml version or is it too
> untested?

Not in the upcoming version, but maybe in the next.
The semantics are a bit tricky, and we don't want to put possibly
wrong code in the official distribution.
A known issue is the interaction with dynamic loading. In most cases
it should be ok, but one can imagine bad scenarii.

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] Five Questions about Objects

[Alain Frisch]

On Sun, 14 Jul 2002, YAMAGATA yoriyuki wrote:

> However, I wonder why a class is necessary in the first place.  I'm
> not familiar with the theory of OOP, but I feel like direct creation
> of objects is possible in functional languages.

It is already possible in OCaml, thanks to local modules:

"object ... end"
===>
let module M = struct class o = object ... end end in new M.o

It would be straightforward to define a Camlp4 syntax extension for this.

-- Alain

-------------------
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] Five Questions about Objects

[Jacques Garrigue]

From: Alain Frisch <frisch@clipper.ens.fr>
> On Sun, 14 Jul 2002, YAMAGATA yoriyuki wrote:
> 
> > However, I wonder why a class is necessary in the first place.  I'm
> > not familiar with the theory of OOP, but I feel like direct creation
> > of objects is possible in functional languages.
> 
> It is already possible in OCaml, thanks to local modules:
> 
> "object ... end"
> ===>
> let module M = struct class o = object ... end end in new M.o
> 
> It would be straightforward to define a Camlp4 syntax extension for this.

This only works if your object has a monomorphic type.

The real point is that if object definitions were really first class
in the language, they would not be restricted by these strange
variable binding conditions: type inference would be enough.
Since there is no theoretical problem here, it may well be a useful
extension.

  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] Five Questions about Objects

[William Lovas]

On Sun, Jul 14, 2002 at 06:38:42PM +0900, Jacques Garrigue wrote:
> This only works if your object has a monomorphic type.
> 
> The real point is that if object definitions were really first class
> in the language, they would not be restricted by these strange
> variable binding conditions: type inference would be enough.
> Since there is no theoretical problem here, it may well be a useful
> extension.

I was thinking about this recently, and it occurs to me that first class
object definitions would provide something equivalent to polymorphicly
typed records.  This would be a nice dual to the polymorphic variants
already in the language, i think.  Are there any plans for such an 
extension?  Would such an extension be feasible?

William
-------------------
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] Five Questions about Objects

[Xavier Leroy]

> A few questions on objects:

To complement the replies you already got:

> 2) What is the point of "class" and "new" keywords? How are they better than 
> "let" ? E.g.
> 
> let point a b = 
>   object
>     val x = a
>     val y = b
>     method get () = (x, y)
>   end;;
> 
> let my_point = point 3 7;; 
> let many_float_points = Array.make 100 (point 4.0 3.0);;
> ?

The main purpose of the class system is to support inheritance and
method overriding.  Object-oriented programming comes in two flavors:
class-based OOP, which is what all mainstream OO languages offer, and
delegation-based OOP, where there are no classes, objects are built
directly by listing their fields and methods like you suggested, and
method overriding is performed directly on objects, e.g. via a "copy
this object, replacing these methods" operation.  While there have
been some theoretical work on delegation-based OOP, I think it is fair
to say that it is less well understood than class-based OOP.

> 4) Can I construct an object that the following function f would accept?
> # let f a = a#m1 (); a#b#m2 ();;
> val f : < b : < m2 : unit -> 'a; .. >; m1 : unit -> 'b; .. > -> 'a = <fun>
> 
> I tried the obvious (to me) and it doesn't work. What is the precedence and 
> associativity of #?

# is not associative because it is not really a binary operator.  In
other terms, a#(b#m2) doesn't make sense because the right-hand side
of the # sign must be a method name, not the result of a computation.

As for your example, just read the type of f aloud: the argument to f
should be an object having at least an "m1" method and a "b" method;
"b" should return an object having at least an "m2" method.

> 5) What is the current state of marshalling objects? Is Jacques's
> patch going to be used in the upcoming O'Caml version or is it too
> untested?

It's not going in the next release because the working sources are in
"code freeze" state, meaning we fix bugs but don't add features.  It
might be merged in afterwards provided some minor technical issues are
fixed.  But at any rate this only provides a limited form of
marshalling where the program that reads back the marshalled object
must be *exactly identical* to the program that marshalled the object.
There are cases where this restriction is OK (e.g. SPMD programming),
and others where it makes object marshalling inadequate
(e.g. databases, general distributed programming).

- Xavier Leroy
-------------------
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] Five Questions about Objects

[Oleg]

On Sunday 14 July 2002 11:47 am, Xavier Leroy wrote:
> > 2) What is the point of "class" and "new" keywords? How are they better
> > than "let" ? E.g.
> > 
> > let point a b =
> >   object
> >     val x = a
> >     val y = b
> >     method get () = (x, y)
> >   end;;
> > 
> > let my_point = point 3 7;;
> > let many_float_points = Array.make 100 (point 4.0 3.0);;
> > ?
>
> The main purpose of the class system is to support inheritance and
> method overriding.  Object-oriented programming comes in two flavors:
> class-based OOP, which is what all mainstream OO languages offer, and
> delegation-based OOP, where there are no classes, objects are built
> directly by listing their fields and methods like you suggested, and
> method overriding is performed directly on objects, e.g. via a "copy
> this object, replacing these methods" operation.  While there have
> been some theoretical work on delegation-based OOP, I think it is fair
> to say that it is less well understood than class-based OOP.

I thought my suggestion had to do with syntax only. One could still write 
things like 

type color = Red | Green | Blue

let pixel a b (c:color) = 
  object
    inherit point a b as p
    val col = c
    method get_color () = col
    method get_coords () = p#get ()
  end

I don't really see any significant "OO flavor" difference, just simpler and 
more consistent syntax IMHO: two keywords are eliminated, and class 
definition is now just function definition. If that is not the case, can you 
give examples in current O'Caml syntax that do not translate well into this 
"syntax" ?

Thanks
Oleg
-------------------
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] Five Questions about Objects

[Oleg]

On Sunday 14 July 2002 11:47 am, Xavier Leroy wrote:
> > 4) Can I construct an object that the following function f would accept?
> > # let f a = a#m1 (); a#b#m2 ();;
> > val f : < b : < m2 : unit -> 'a; .. >; m1 : unit -> 'b; .. > -> 'a =
> > <fun> 

[...]

> As for your example, just read the type of f aloud: the argument to f
> should be an object having at least an "m1" method and a "b" method;
> "b" should return an object having at least an "m2" method.

To me, " b : < m2 : unit -> 'a; ...>" seems to mean the following: "b" IS an 
object having at least "m2" method of type "unit -> 'a". Just like m1 is 
"m1 : unit -> 'b" above, not "m1 : 'b".

Had the toplevel said 
val f : < b : unit -> < m2 : unit -> 'a; .. >; m1 : unit -> 'b; .. > -> 'a 
It would have meant the same thing to me as it does to you in its present 
reading.

Regards,
Oleg
-------------------
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] Five Questions about Objects

[YAMAGATA yoriyuki]

From: Brian Smith <blsmith@blue.weeg.uiowa.edu>
Subject: Re: [Caml-list] Five Questions about Objects
Date: Sat, 13 Jul 2002 21:41:32 -0500

> Also, class types are types, and classes define implicit types, so I 

Class types are equivalent of module types for classes.  They are not
types, though class type declaration defines a type with the same
name.  All your examples (coercion, #-expression) are about types, not
classes nor class types.

So, classes make a new category of "things" in ocaml.  Honestly, I
don't like this "ontological bloat".  I'm still wondering whether
objects, classes and class types can be subsumed to values, types or
even modules.

--
Yamagata Yoriyuki
http://www.mars.sphere.ne.jp/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