Re: [Caml-list] OO programming

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: "Tiphaine.Turpin" <Tiphaine.Turpin@free.fr>

> First, my desired use of objects is not (reduced to) programming a gui. 
> I can imagine that, in guis, the actions that may be invoked on objects 
> or that may originate from them are just signals with rather simple 
> types, which form a simple case of object communication for which action 
> connection is enough, but when it comes to using objects to model the 
> objects of the application domain, stronger links (i.e., fields) are 
> sometimes natural. Note that, in class diagrams, links between classes 
> are one of the most basic concepts.

My point was that it's not because it is a good concept that it is
necessarily a good programming technique. That is, you might want to
right your class diagram with links between classes, but use an
indirection at the connection level in your implementation, if it
makes things simpler. I see no contradiction there. But as I wrote in
my previous mail, OO people often prefer to have their concepts
directly apparent in their programs.

> > But I think your disagreement lies at a  different level: OO
> > programmers often want to express their own view of things directly
> > into the language.
> Yes. Clearly, I want the abstractions, patterns, etc. I have in mind to 
> be expressed themselves as language objects, and not just their 
> "instanciation". Isn't this the very goal of high-level languages after 
> all ?

Yes, but the ocaml approach is to define entities independently, and
let types handle the interconnections. This does not fit well with
class diagrams. So if you want to keep your class diagram apparent,
you need painful contorsions.

Note also that your original goal, being able to extend families of
classes at the type level, is an active research area. When ocaml was
created, there was no OO language able to do it explicitly, or even
implicitly (as ocaml does). Now you might have your chance with Scala
or gBeta.

> >   Klaus Ostermann. Nominal and structural subtyping in component-based
> >   programming. Journal of Object Technology, 7(1):121 - 145, 2008.
> >   
> An interesting reading. The expressive power that he adds to nominal 
> subtyping gives me more arguments to consider structural subtyping not 
> very usefull (but I understand that structural is much more consistent 
> with everything else in ocaml).

Not really. He build his nominal subtyping as an extension of
structural subtyping. And I'm personally not sure that the nominal
part gets him much (out of better error messages, which do matter)

> >> Hence my question: does anyone knows a way of combining the reusability 
> >> of sets of related classes with a more modular (type/consistency)-checking ?
> >>     
> >
> > I'm not sure whether it helps, but I attach here the same example of
> > observer pattern as in the tutorial,
> which tutorial ?

Section 5.3 of the reference manual, which is a variation on the one
you were mentionning.

> >  but without using type parameters. They are replaced by private row types.
> >   
> which is very verbose (having to explicitely write class types), and I'm 
> not sure I understand the benefits of doing this.

Verbose indeed. I didn't say this was the right way to do it, just
that it lets you express more relations in the interfaces.

> > Ideally, one would like to check coherence too by writing
> >   module rec Check : S' = Window(Check)
> > Unfortunately, this doesn't seem to work currently. I'm not yet sure
> > whether this is a bug or a limitation of recursive modules.
> >   
> If the typing of recursive modules just types the body of each module in 
> the environment given by the declared module types of all modules 
> involved in the recursive definition, then this cannot work, since 
> Window(Check) would have to be of type S' for any Check : S', which is 
> clearly false (e.g. Check = struct ... type  observer = <foo: unit; 
> notify : ...).

No, the typing of recursive modules is much more clever, otherwise it
wouldn't be useful. So, conceptually, this could work.
For instance, if you drop the ability to add methods to the observer,
the check goes through:

module type S' = sig
  type event = private [> `Move]
  type subject = private <draw: unit; ..>
  type observer = <notify: subject -> event -> unit>
end

module Window(X:S') = struct
  module AX = Any(X)
  type event = X.event
  class observer =
    object
      inherit AX.observer
      method notify s e = s#draw
    end
  let count = ref 0
  class virtual subject =
    let id = count := succ !count; !count in
    object (self)
      inherit AX.subject
      val mutable position = 0
      method identity = id
      method move x = position <- position + x; self#notify_observers `Move
      method draw = Printf.printf "{Position = %d}\n"  position;
    end
end

module rec Check : S' = Window(Check)

This way you can see that subject and observer are compatible without
providing concrete instances.

However, when the observer and subject have both extensible types,
there seems to be an interaction between nominal and structural types,
and the knot cannot be tied.

> As for extension, I'm fully satisfied. But the verbosity level is 
> annoying for scalability...

Well, yes, that's always the problem with functors...

Jacques Garrigue