Re: [Caml-list] OO programming

[Dirk Thierbach <dthierbach@gmx.de>]

On Mon, Feb 25, 2008 at 10:23:09AM +0100, Tiphaine.Turpin wrote:
> Dirk Thierbach a écrit :
> >On Thu, Feb 21, 2008 at 10:31:42AM +0100, Tiphaine Turpin wrote:

> No connecting of objects, therefore no mutually recursive methods, (and 
> many arguments added to every function to carry the missing context), 
> little mutable state, and no use of class names to specify types... I'm 
> sure that many problems go away in this setting, and there are still 
> advantages to using objects (inheritance, etc.) 

Let me repeat: The main advantage of OO is that you can group related
state together, and that you can "push" changes (events, secondary
changes caused by events, whatever) onto this network of state.

While the functional way (especially with lazy computations) is to
"pull" a result from a network of computations. 

> but isn't this a somewhat degraded version of the object paradigm ?

Well, people can't seem to agree what exactly the "object paradigm"
actually is in the first place :-). Personally, I don't care. I want
clean, flexible, decoupled code. I am not interested in doing something
just because eomeone tells me, possible mistakenly, that I have to
follow "the" paradigm.

>> Much more annoying is that one also has to give types to arguments in
>> methods that are unused (they are present make them compatible with
>> another class, which uses them;

> which is where I think mutually recursive classes would be usefull, if 
> their typing was easier.

Mutual recursive classes won't solve this problem at all. Maybe an 
example helps: In a GUI, one can get various sorts of events, say,
a "resize" event. If the method connected to that event is only
interested in the new width and not in the height, so it doesn't
use this value at all, you have to declare the type. No other class
involved at all.

>> I'd really appreciate it if one could just mix "val" type
>> declcarations with "let" or "method" code declarations.

> I don't understand what you want here.

See Edgar's response. But that was only just a side-remark.

>>> Of course, the resulting classes should be reusable, that is, one
>>> should be able to extend a collection of related classes
>>> simultaneously, such that the fields now have the relevant subtype
>>> instead of the type they had before.

>> Not sure what exactly you mean here. Could you give an example?

> I will try to state at an abstract level what I would like to do :
> 
> - define parametric virtual classes A and B so that every A has a Bs 
> (one or many...) and vice-versa.
> - possibly extend A and B to A' and B' respectively, so that every A' 
> has B's (and not just Bs), etc.
> - subtyping: possibly extend B to B1 and B2 so that their objects have 
> As, but those As still have Bs, so that I can associate the same A to 
> objects of class B, B1 or B2.
> 
> - and the ultimate goal combining all that: define A and B as above, 
> other virtual classes C and D in a similar way and E and F too, and 
> define concrete classes X Y Z1 Z2 just by saying that X extends A, Y 
> will play the role of B in the first two classes and the role of C in 
> the last two ones, and Z1 Z2 extends D (both) and E and F 
> (respectively). It happens that some of the types that were left 
> parametric (respectively methods defined as virtual) in B are made 
> concrete in C, (and so on), so I obtain my final concrete classes.

If you manage to find a simple type system for that, preferably with
type inference and principal typings, I'd like to see it :-)

> For now, I found many introductions on ocaml objects using and how to 
> actually use them (Ocaml manual, Didier Remy's course, the "Developing 
> applications with Objective Caml" book, as suggested by Julien Moutinho, 
> and also Philippe Narbel's book) but none of them went that far.

So maybe there's a reason they are doing it differently. :-) You
can fight the system, and try to make everything difficult because you
think "it ought to be this way", or you can go the easy route. Your
choice. I can only tell you what I found that works for me.

- Dirk