[Caml-list] Recovering masked methods

[Caml-list] Recovering masked methods

[Alessandro Baretta]

I have code similar to the following

class a =
object (self)
   method m = 1
   method n = "Hello!"
end

class b =
object (self)
   inherit a as super_a
   method m = 2
end

Now I would like to define a third class, inheriting from b. 
  I need this class to be able to access the definition of 
method m from class a, otherwise I would have to use "copy & 
paste", which is contrary to my programmer's ethics.

Ideally, I would like to write

class c =
object (self)
   inherit b as super_b

   method m =
     (* some_stuff *)
     super_b # super_a # m
end

Presently, this is not allowed. Is there any specific reason 
for this? Could such a feature be implemented in the future?

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] Recovering masked methods

[Jacques Garrigue]

From: Alessandro Baretta <alex@baretta.com>

> I have code similar to the following
> 
> class a =
> object (self)
>    method m = 1
>    method n = "Hello!"
> end
> 
> class b =
> object (self)
>    inherit a as super_a
>    method m = 2
> end
> 
> Now I would like to define a third class, inheriting from b. 
>   I need this class to be able to access the definition of 
> method m from class a, otherwise I would have to use "copy & 
> paste", which is contrary to my programmer's ethics.

You don't need to be too ethical about that.
What's so great about strong typing, is that it makes copy-paste work!

And you can always write

let a_m = 1
class a = ... method m = a_m ..

This way you can still share the code (but you need to pass private
methods by hand).

If you want to stay indide the object, you can also save the old
method to a private one:

class b = ... method private a_m = super_a#m ...

> Ideally, I would like to write
> 
> class c =
> object (self)
>    inherit b as super_b
> 
>    method m =
>      (* some_stuff *)
>      super_b # super_a # m
> end
> 
> Presently, this is not allowed. Is there any specific reason 
> for this? Could such a feature be implemented in the future?

OK, you want something like C++'s qualified calls?
There's no project to do that. Methods do not exist independently of
their class.
Another approach would be to provide views, as described by Jerome
Vouillon. That is, an object could keep some extra sets of methods in
an abstract way. But there's not project to implement that either.

Yet, it's not even clear such an ancestor call would make sense in
general.
Could you give some more compelling example requiring such a feature?

      Jacques
-------------------
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] Recovering masked methods

[Alessandro Baretta]

Jacques Garrigue wrote:
> From: Alessandro Baretta <alex@baretta.com>

>>Now I would like to define a third class, inheriting from b. 
>>  I need this class to be able to access the definition of 
>>method m from class a, otherwise I would have to use "copy & 
>>paste", which is contrary to my programmer's ethics.
> 
> 
> You don't need to be too ethical about that.
> What's so great about strong typing, is that it makes copy-paste work!

:-)

> And you can always write
> 
> let a_m = 1
> class a = ... method m = a_m ..

This is not viable. The toy code I have shown here does not 
provide any real functionality, but in the real application 
you have to imagine the following situation:


class a =
object (self)
   method m = <some generally useful stuff
   method m1 = <other generally useful stuff>
   ...
   method mn = <other generally useful stuff>
end

class b =
object (self)
   inherit a as super_a
   method m = <specific stuff>; super_a # m
   method m1 = <specific stuff>; super_a # m1
   ...
   method mn = <specific stuff>; super_a # mn
end


class small_variant_of_b =
object (self)
   inherit b as super_b
   method m = super_b # super_a # m
(* All the specific stuff in method m is not needed *)
(* Yet, all other methods must be inherited from b  *)
end


Without the above notation, I could only think of copying 
the code of method m out of class a and pasting it into 
class small_variant_of_b, but this makes maintainance a 
mess. And I am working on a production class system. No 
good. However, I did not consider the following idea, which 
is not bad indeed. In the absence of the notation I 
described above, or of an equivalent one, I'll do as you 
propose here.

> If you want to stay indide the object, you can also save the old
> method to a private one:
> 
> class b = ... method private a_m = super_a#m ...
> 
> 
>>Ideally, I would like to write
>>
>>class c =
>>object (self)
>>   inherit b as super_b
>>
>>   method m =
>>     (* some_stuff *)
>>     super_b # super_a # m
>>end
>>
>>Presently, this is not allowed. Is there any specific reason 
>>for this? Could such a feature be implemented in the future?
> 
> 
> OK, you want something like C++'s qualified calls?
> There's no project to do that. Methods do not exist independently of
> their class.
> Another approach would be to provide views, as described by Jerome
> Vouillon. That is, an object could keep some extra sets of methods in
> an abstract way. But there's not project to implement that either.

You are getting too technical for me. I'm not a compiler 
guru, only a user, so I'm not sure what could or should be 
done. Let me propose a syntax which might make things clearer.

class a =
object
   ...
end

class b =
object
   inherit a
   ...
end

class c =
object
   inherit a as super_a through b as super_b { through 
<class> as <identifier> }*
...
end

Let me call this syntax "explicit inheritance hierarchy 
relation". This syntax is only viable if we assume that 
extending a working class library never requires to *insert* 
a class between two classes in a relation of inheritance. 
Such extensions would break the above code. I don't believe 
this limitation would have any real impact on the the 
usability of the language or of this extension.

> Yet, it's not even clear such an ancestor call would make sense in
> general.
> Could you give some more compelling example requiring such a feature?

I a method m in class b can call a method x in super_a 
(which is class a), and a method m' in class b' can call
a method m in super_b (which is class b), then, by 
transitity, a method in class b' can call a method x in 
super_a. All we need is some syntactic sugar to make this 
happen "automagically". But I would not rely on CamlP4 for 
this: the syntax extension would not have a local impact, so 
we need help from the compiler.

Let me know what you think.

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] Recovering masked methods

[Laurent Vibert]

On Tue, 16 Jul 2002, Alessandro Baretta wrote:

> class a =
> object
>    ...
> end
> 
> class b =
> object
>    inherit a
>    ...
> end
> 
> class c =
> object
>    inherit a as super_a through b as super_b { through 
> <class> as <identifier> }*
> ...
> end
> 

isn't multiple inheritance enougth for this ?

class c =
  object
    inherit a as super_a
    inherit b as super_b
    method m = super_a # m
    (* other method are left unchanged *)
  end

-------------------
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] Recovering masked methods

[Johan Baltié]

> On Tue, 16 Jul 2002, Alessandro Baretta wrote:
> 
> > class a =
> > object
> >    ...
> > end
> > 
> > class b =
> > object
> >    inherit a
> >    ...
> > end
> > 
> > class c =
> > object
> >    inherit a as super_a through b as super_b { through 
> > <class> as <identifier> }*
> > ...
> > end
> > 
> 
> isn't multiple inheritance enougth for this ?
> 
> class c =
>   object
>     inherit a as super_a
>     inherit b as super_b
>     method m = super_a # m
>     (* other method are left unchanged *)
>   end

And if
 class c =
   object
     inherit a as super_a
     inherit b as super_b
   end

Which one "c#m" will call ?

By experiments c#m = b#m, but 
 class c =
   object
     inherit b as super_b
     inherit a as super_a
   end

means c#m = a#m....

I do not even know what kindda behavior a "virtual" will generate !
Is there any way to forbid such dangerous thing ?

Ciao

Jo
-------------------
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] Recovering masked methods

[Alessandro Baretta]

Laurent Vibert wrote:
> On Tue, 16 Jul 2002, Alessandro Baretta wrote:
>>class c =
>>object
>>   inherit a as super_a through b as super_b { through 
>><class> as <identifier> }*
>>...
>>end
>>
> 
> 
> isn't multiple inheritance enougth for this ?
> 
> class c =
>   object
>     inherit a as super_a
>     inherit b as super_b
>     method m = super_a # m
>     (* other method are left unchanged *)
>   end
> 
> 

Definitely not. By using multiple inheritance as you 
suggest, class c inherits from class a *twice*, thereby 
having double copies of all instance variables declared in 
a. This is bad. Consider how difficult it is to manage a 
multiple-path inheritance in C++, and how that has rendered 
necessary the use of "virtual" memember objects.

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] Recovering masked methods

[Johan Baltié]

> [sniped]
> 
> > And you can always write
> > 
> > let a_m = 1
> > class a = ... method m = a_m ..
> 
> This is not viable. The toy code I have shown here does not 
> provide any real functionality, but in the real application 
> you have to imagine the following situation:
> 
> class a =
> object (self)
>    method m = <some generally useful stuff
>    method m1 = <other generally useful stuff>
>    ...
>    method mn = <other generally useful stuff>
> end
> 
> class b =
> object (self)
>    inherit a as super_a
>    method m = <specific stuff>; super_a # m
>    method m1 = <specific stuff>; super_a # m1
>    ...
>    method mn = <specific stuff>; super_a # mn
> end
> 
> class small_variant_of_b =
> object (self)
>    inherit b as super_b
>    method m = super_b # super_a # m
> (* All the specific stuff in method m is not needed *)
> (* Yet, all other methods must be inherited from b  *)
> end
> 
> Without the above notation, I could only think of copying 
> the code of method m out of class a and pasting it into 
> class small_variant_of_b, but this makes maintainance a 
> mess. And I am working on a production class system. No 
> good. However, I did not consider the following idea, which 
> is not bad indeed. In the absence of the notation I 
> described above, or of an equivalent one, I'll do as you 
> propose here.

I do not agree with you on the usefullness of this kind of stuff.
Basic OO theory says that the inheritance relation can be seen as a "is a" operator.

If your "is a" means "is a with some variants", for me your modelization is not
good.

You should have:

 B' inherits A 
 B inherits B'
 small_b_variant inherits B'

Like this code factorisation seems to be easy to do. 

IMHO it's a good modelization constraint to forbid such stuff.

> [resniped]

Ciao

Jo
-------------------
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] Recovering masked methods (with CamlP4?)

[Alessandro Baretta]

Johan Baltié wrote:
> 
> I do not agree with you on the usefullness of this kind of stuff.
> Basic OO theory says that the inheritance relation can be seen as a "is a" operator.
> 
> If your "is a" means "is a with some variants", for me your modelization is not
> good.
> 
> You should have:
> 
>  B' inherits A 
>  B inherits B'
>  small_b_variant inherits B'
> 
> Like this code factorisation seems to be easy to do. 
> 
> IMHO it's a good modelization constraint to forbid such stuff.

I strongly disagree. Inheritance, as pointed out previously 
by someone on this list (I can't remember whom), is a 
syntactic property of classes, whereas subtyping is a 
semantic property of instances. Just now I have received a 
post by John Prevost clarifying this.

In my code,
class a = object method m = ... end
Provides basic functionality common to all my inheritance 
hiearchy. Class a *also* defines the actual type of all my 
inheritance hieararchy, so I do not use subtyping at all; I 
use type *identity*. That's because I'm building a graph of 
objects of different classes, so all the objects in the 
graph need to have the same type. I only use inheritance 
because of code sharing. Now,
class b = object inherit a ... end
performs extensive personalizations to the functionality 
provided by class a, while always retaining the 
functionality of the parent, which is accessed by sending 
messages to super_a. Class var_b needs most of the 
functionality provided by b, with the sole exception of one 
method, which I call here m, which needs to be identical to 
the one defined in the root of the hierarchy. Hence, for the 
sake of code reuse, since var_b shares most of its code with 
b, it must inherit from b; however, for the sake of not 
having multiple copies of the same lines of code--a 
maintainance issue--I *also* need var_b to inherit, albeit 
indirectly, form a. This is my reason for requesting and 
"explicit inheritance hierarchy" construct. I think it 
should pose no semantic issues with the OO system of Caml. 
It should simply allow explicit scoping of inherited 
methods. Please, note that it is merely a bit of syntactic 
sugar. To think of it, it might even be implemented with CamlP4.

CamlP4 could perform the following code transformation:
class a =
object
   method m = <some stuff>
end

to
class a =
object
   private method __class_a__m = <some stuff>
   method m = self # __class_a__m
end

and

class var_b =
object
   inherit a as super_a through b as super_b
   method m = super_a # m
end

to

class var_b =
object
   inherit b as super_b
   method m = __class_a__m
end

Daniel, I'm no CamlP4 guru. Would this scheme work?

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] Recovering masked methods (with CamlP4?)

[Johan Baltié]

> Johan Baltié wrote:
> > 
> > I do not agree with you on the usefullness of this kind of stuff.
> > Basic OO theory says that the inheritance relation can be seen as a "is a"
operator.
> > 
> > If your "is a" means "is a with some variants", for me your modelization is not
> > good.
> > 
> > You should have:
> > 
> >  B' inherits A 
> >  B inherits B'
> >  small_b_variant inherits B'
> > 
> > Like this code factorisation seems to be easy to do. 
> > 
> > IMHO it's a good modelization constraint to forbid such stuff.
> 
> I strongly disagree. Inheritance, as pointed out previously 
> by someone on this list (I can't remember whom), is a 
> syntactic property of classes, whereas subtyping is a 
> semantic property of instances. Just now I have received a 
> post by John Prevost clarifying this.

Uhh ? I have missed something. Can you forward me this post privately ? I cannot
find it. It seems awful to me to hear that inheritance is "syntactic", because
it does mean (for me) that nothing happen at runtime.

> In my code,
> class a = object method m = ... end
> Provides basic functionality common to all my inheritance 
> hiearchy. Class a *also* defines the actual type of all my 
> inheritance hieararchy, so I do not use subtyping at all; I 
> use type *identity*. That's because I'm building a graph of 
> objects of different classes, so all the objects in the 
> graph need to have the same type. I only use inheritance 
> because of code sharing. Now,
> class b = object inherit a ... end
> performs extensive personalizations to the functionality 
> provided by class a, while always retaining the 
> functionality of the parent, which is accessed by sending 
> messages to super_a. Class var_b needs most of the 
> functionality provided by b, with the sole exception of one 
> method, which I call here m, which needs to be identical to 
> the one defined in the root of the hierarchy. Hence, for the 
> sake of code reuse, since var_b shares most of its code with 
> b, it must inherit from b; however, for the sake of not 
> having multiple copies of the same lines of code--a 
> maintainance issue--I *also* need var_b to inherit, albeit 
> indirectly, form a. This is my reason for requesting and 
> "explicit inheritance hierarchy" construct. 

You say "since var_b shares most of its code with b, it must inherit from b".
If you do not like my little B' class (I do not understand why), then say "b
share most of this code with var_b, it must inherit from var_b", with b a
specialization of var_b.

For me it's still modelization problem.

Ciao

Jo
-------------------
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] Recovering masked methods (with CamlP4?)

[Alessandro Baretta]

Johan Baltié wrote:

> Uhh ? I have missed something. Can you forward me this post privately ? I cannot
> find it. It seems awful to me to hear that inheritance is "syntactic", because
> it does mean (for me) that nothing happen at runtime.
> 

I've been looking for the exact post, but I can't find it. I 
remember distictly to have read something like that a little 
while ago, yet I cannot find the message.

Anyhow, insofar as I have understood the workings of the 
Ojbective part of the Caml, class inheritance is merely 
supposed to be a form of type safe code reuse (something of 
a macroexpansion to use C/++ terminology). In C++, if class 
B inherits from class A, B *is an* A. In O'Caml this is not 
true. B has all the functionality (read, "methods") provided 
by A. Nowhere is it guaranteed to be either type-equivalent 
to or a subtype of A. Therefore, an instance of B cannot be 
used wherever an instance of A can be used. And even if B 
*is a subtype* of A, then instances of B must be explicitly 
coerced to having type A (this amounts to method hiding, 
AFAIK) before they can be used as actual parameters to 
funtions whose formal parameter is of type A.

An example of this feature is Pxp's parse_document entity 
function. In order to check che validity of the use of ID 
and IDREF attribute fields in an XML document, the above 
function must be passed an object of type index = < 
{some_methods} >. But this is only a class type (an 
interface à la Java). Gerd Stolpmann provides an 
implementation class hash_index which is a sub_type of of 
index (implements the interface), but adds one extra method. 
In order to pass an object instance of hash_index to 
parse_document_entity you have to explicitly coerce it to 
having type index.

This is why it is perfectly sensible to let class 
variant_of_b inherit from class b, although the two classes 
*are not* in an "is a" relation with one another. You get 
the benefit of inheriting all the code in b which is also 
needed in variant_of_b, all the while retaining the 
possibility of adding methods to variant_of_b such that 
variant_of_b *is not a* b.

This approach to inheritance is radically different from 
that of C++. It takes a while to get the hang of it. It's 
actually much more powerful.

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] Recovering masked methods (with CamlP4?)

[Daniel de Rauglaudre]

Hi,

On Tue, Jul 16, 2002 at 01:08:08PM +0200, Alessandro Baretta wrote:

> CamlP4 could perform the following code transformation:
> [...]
> Daniel, I'm no CamlP4 guru. Would this scheme work?

No problem. Do you want the code?

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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] Recovering masked methods (with CamlP4?)

[Alessandro Baretta]

Daniel de Rauglaudre wrote:
> Hi,
> 
> On Tue, Jul 16, 2002 at 01:08:08PM +0200, Alessandro Baretta wrote:
> 
> 
>>CamlP4 could perform the following code transformation:
>>[...]
>>Daniel, I'm no CamlP4 guru. Would this scheme work?
> 
> 
> No problem. Do you want the code?
> 

Great! Don't you think this would be a cool addition to the 
language? I like it, at least.

Go ahead. You'll make me learn CamlP4 finally, eh? Well, it 
was on the waiting list anyway...

Thank you very much, Daniel!

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] Recovering masked methods (with CamlP4?)

[Daniel de Rauglaudre]

Hi,

On Tue, Jul 16, 2002 at 02:54:45PM +0200, Alessandro Baretta wrote:

> Great! Don't you think this would be a cool addition to the 
> language? I like it, at least.

I cannot judge if it is a good idea or not: I never program with
objects and I don't know what is useful or not. I just answer the
syntactic point of view. For semantics, please go to the counter
"Semantics".

      -----

For your change:

  class a =
  object
     method m = <some stuff>
  end

into:

  class var_b =
  object
     inherit a as super_a through b as super_b
     method m = super_a # m
  end

You can do it with this file:

------------------------------------------------ foo.ml
#load "pa_extend.cmo";;
#load "q_MLast.cmo";;

open Pcaml

EXTEND
  GLOBAL: class_str_item;
  class_str_item:
    [ [ "method"; l = LIDENT; fb = fun_binding ->
          let class_a = "__class_a__" ^ l in
          <:class_str_item<
            declare
              method private $lid:class_a$ = $fb$;
              method m = self # $lid:class_a$;
            end >> ] ]
  ;
  fun_binding:
    [ RIGHTA
      [ p = patt LEVEL "simple"; e = SELF -> <:expr< fun $p$ -> $e$ >>
      | "="; e = expr -> <:expr< $e$ >>
      | ":"; t = ctyp; "="; e = expr -> <:expr< ($e$ : $t$) >> ] ]
  ;
END
------------------------------------------------

Compile it with:
   ocamlc -pp camlp4o -I +camlp4 -c foo.ml

Then you can compile your example "bar.ml" with the command:
   ocamlc -pp "camlp4o ./foo.cmo" bar.ml

You can also see what the syntax extension does with the command:
   camlp4o ./foo.cmo pr_o.cmo bar.ml

      -----

For the case:

  class var_b =
  object
     inherit a as super_a through b as super_b
     method m = super_a # m
  end

into:

  class var_b =
  object
     inherit b as super_b
     method m = __class_a__m
  end

It could be done by Camlp4 the same way but there is a small difficulty:
it is not really "syntactic sugar" since it supposes, when reaching
the item "method m = super_a # m" that you know that "super_a" has
been previously defined as "inherit a as super_a through b as
super_b".

This is mainly "semantics". I mean that the parser should record
the information that an "inherit" statement has been defined.

It is possible, of course, and I can give you the code which
does that, but is it not supposed to be Camlp4 work, if you want
to be "pure". The code risks to be a "hack". You have probably to
use references to record this information to be possibly used
afterwards.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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] Recovering masked methods (with CamlP4?)

[John Prevost]

>>>>> "ab" == Alessandro Baretta <alex@baretta.com> writes:

    ab> In my code, class a = object method m = ... end Provides basic
    ab> functionality common to all my inheritance hiearchy. Class a
    ab> *also* defines the actual type of all my inheritance
    ab> hieararchy, so I do not use subtyping at all; I use type
    ab> *identity*. That's because I'm building a graph of objects of
    ab> different classes, so all the objects in the graph need to
    ab> have the same type. I only use inheritance because of code
    ab> sharing. Now, class b = object inherit a ... end performs
    ab> extensive personalizations to the functionality provided by
    ab> class a, while always retaining the functionality of the
    ab> parent, which is accessed by sending messages to
    ab> super_a. Class var_b needs most of the functionality provided
    ab> by b, with the sole exception of one method, which I call here
    ab> m, which needs to be identical to the one defined in the root
    ab> of the hierarchy.

Okay--let me rephrase what you just said to make sure I understand
correctly:

You have a class "a" which has a lot of common methods.

You have a class "b" which reuses and changes those.

You have a class "var_b" which is identical to "b" except that method
"m" is the same as "a".

If that is correct, I have no idea why you want to inherit the way
you've been talking about!  Why in heaven's name wouldn't you just
write:

class a =
  object
    method m = ...
    method m1 = ...
    method m2 = ...
    ...
  end

class var_b =
  object
    inherit a
    method m1 = ...
    method m2 = ...
    ...
  end

class b =
  object
    inherit b
    method m = ...
  end

You've simply got the wrong ordering in your inheritance.  There's
absolutely no need for more functionality to support accessing "older"
methods in this case.  (I'd argue there's no need in any case.)  And
again, even if method m had to be different in var_b, it would be
better to use an inherited class which has the features common to b
and var_b.  In this case, that class is identical to b.

John.

-------------------
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] Recovering masked methods (with CamlP4?)

[John Prevost]

And an addendum: If you are resistant to using "intermediate" classes
with pieces of the functionality you need, remember that you can
always hide these classes using module interfaces, and make the
classes virtual so that you don't mistakenly use them in your code.

John.
-------------------
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] Recovering masked methods (with CamlP4?)

[Alessandro Baretta]

John Prevost wrote:

> You've simply got the wrong ordering in your inheritance.  There's
> absolutely no need for more functionality to support accessing "older"
> methods in this case.  (I'd argue there's no need in any case.)  And
> again, even if method m had to be different in var_b, it would be
> better to use an inherited class which has the features common to b
> and var_b.  In this case, that class is identical to b.
> 
> John.


Not a bad idea, actually. From a conceptual standpoint it 
works. It did not occur to me go about coding that way 
because my classes come in "related packages", and given 
this conceptual grouping, it would sort of look funny to 
implement what you suggested.
...
Now that you make me think of it, all I need is an 
intermediate class in my hierarchy, factoring all the the 
common functionality with the exception of two methods: 
let's say m and n. I'll then have a package inherit from the 
common ancestor and redefine m, while the other package 
redefines n. This intermediate layer will remove the need to 
call a method in a farther ancestor.

Thank you for the suggestion.

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] Recovering masked methods (with CamlP4?)

[Johan Baltié]

> John Prevost wrote:
> 
> > You've simply got the wrong ordering in your inheritance.  There's
> > absolutely no need for more functionality to support accessing "older"
> > methods in this case.  (I'd argue there's no need in any case.)  And
> > again, even if method m had to be different in var_b, it would be
> > better to use an inherited class which has the features common to b
> > and var_b.  In this case, that class is identical to b.
> > 
> > John.
> 
> Not a bad idea, actually. From a conceptual standpoint it 
> works. It did not occur to me go about coding that way 
> because my classes come in "related packages", and given 
> this conceptual grouping, it would sort of look funny to 
> implement what you suggested.
> ...
> Now that you make me think of it, all I need is an 
> intermediate class in my hierarchy, factoring all the the 
> common functionality with the exception of two methods: 
> let's say m and n. I'll then have a package inherit from the 
> common ancestor and redefine m, while the other package 
> redefines n. This intermediate layer will remove the need to 
> call a method in a farther ancestor.
> 
> Thank you for the suggestion.
> 
> Alex
 
I think I express myself very badly because it sounds like my little B' class....

*sigh* 
:,(



Ciao

Jo
-------------------
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] Recovering masked methods (with CamlP4?)

[Alessandro Baretta]

Johan Baltié wrote:
> I think I express myself very badly because it sounds like my little B' class....
> 
> *sigh* 
> :,(
> 
> 
> 
> Ciao
> 
> Jo
> 

I am terribly sorry. But, as I have already had occasion to 
mention, in the past few days I have been coding too much 
and sleeping too little. A good many of my neurons are 
already on vacation. Do excuse them, please.

Anyway, my class hierarchy is a mess. I'm still unsure as to 
what I'll end up doing. Maybe I'll just go and make myself a 
coffee.

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] Recovering masked methods (with CamlP4?)

[Eray Ozkural]

Hi Alessandro,

On Tuesday 16 July 2002 14:08, Alessandro Baretta wrote:
>
> I strongly disagree. Inheritance, as pointed out previously
> by someone on this list (I can't remember whom), is a
> syntactic property of classes, whereas subtyping is a
> semantic property of instances. Just now I have received a
> post by John Prevost clarifying this.
>

Precisely. Languages that the "software engineering" culture have spawned 
adopt a less-than-rational view of the matter. They have not been able to 
distinguish typing from inheritance. The most famous of those languages is 
C++. Although C++ tries to make a difference between "private" and "public" 
inheritance, it's still a disasterous object system.

I think this distinction becomes much clearer in a theoretical analysis of 
class based languages. When we compare the prominent object oriented 
languages, it is much easier to see that the approach of ocaml is the logical 
generalization of object systems found in imperative languages.

That is also how ocaml puts orthogonality back in the equation.

Still, I observe some well-known flaws in the whole of ocaml object system; 
but those are hard to overcome in a graceful extension of core caml such as 
ocaml.

Regards,

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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] Recovering masked methods

[John Prevost]

>>>>> "ab" == Alessandro Baretta <alex@baretta.com> writes:

    ab> This is not viable. The toy code I have shown here does not
    ab> provide any real functionality, but in the real application
    ab> you have to imagine the following situation:

class a =
object (self)
   method m = <some generally useful stuff
   method m1 = <other generally useful stuff>
   ...
   method mn = <other generally useful stuff>
end

class b =
object (self)
   inherit a as super_a
   method m = <specific stuff>; super_a # m
   method m1 = <specific stuff>; super_a # m1
   ...
   method mn = <specific stuff>; super_a # mn
end


class small_variant_of_b =
object (self)
   inherit b as super_b
   method m = super_b # super_a # m
(* All the specific stuff in method m is not needed *)
(* Yet, all other methods must be inherited from b  *)
end

    ab> Without the above notation, I could only think of copying the
    ab> code of method m out of class a and pasting it into class
    ab> small_variant_of_b, but this makes maintainance a mess. And I
    ab> am working on a production class system. No good. However, I
    ab> did not consider the following idea, which is not bad
    ab> indeed. In the absence of the notation I described above, or
    ab> of an equivalent one, I'll do as you propose here.

Just as a note, I would argue that doing the above is an indication
that you're over-using class inheritance.  If you need access to the
method "m" in both "a" and "b", then it's not really the same method.
If you need access to only one or the other (in this case, only the
one in a), how about:

class a =
  object
    method m = ...
    method m1 = ...
    ...
    method mn = ...
  end

class b' =
  object
    inherit a as s
    method m1 = ...; s #m
    ...
    method mn = ...; s #mn
  end

class b =
  object
    inherit b' as s
    method m = ...; s #m
  end

class var_b =
  object
    inherit b' as s
    method m = ...; s #m
  end

Remember that unlike most class-based languages, object *typing* in
O'Caml is orthogonal to inheritance.  Even though var_b does not
inherit from b, as long as method m has the same type signature,
they're compatible.  Since this is true, you should subclass purely to
share functionality--and in this case, you have two classes that share
functionality: b and the variant of b.  In fact, they share code for
everything except method m.

Isn't this a perfect example of when you *do* want to use inheritance
for code sharing?


Note that this is actually one place where the proper use of
inheritance is different from that in most OO contexts.  In most OO
languages, you should only subclass when you want to subtype.  That
is, subclasses of a given class should exist because each subclass is
a kind of the thing defined by the superclass.  Much OO literature
recommends *against* subclassing simply for purposes of sharing code,
because it complicates the control flow and can lead to subtle errors.

In O'Caml, you need not subclass to get subtyping.  In fact,
subclassing does not necessarily produce a subtype.  So by contrast,
in O'Caml the only time you ever should subclass is if you intend to
re-use code.  It's still true that this can complicate the control flow
and lead to subtle errors--but since subtyping is separate, there's no
need to subclass at all unless you're re-using code.

A very good example of this is an example that used to exist in the
O'Caml manual (I think) of linked lists and doubly linked lists.  In
O'Caml, it's reasonable to define doubly linked lists as inheriting
from linked lists in order to share code.  However: doubly linked
lists are not type-compatible with linked lists, so they're not a
subtype.

So: inherit in moderation.


John.
-------------------
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