Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Restricting Method Overriding/Redefinition in Subclass
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-08-14 (00:03)
From: chris.danx <chris.danx@n...>
Subject: [Caml-list] Restricting Method Overriding/Redefinition in Subclass

Methods provide access control in the form of private or public methods, 
but I am in a position where I would like the client to extend some 
methods but not others, and would like some advice if possible.

class type virtual base_class =
    object (self)

    method add_child    (c : base_class) -> unit
    method remove_child (c : base_class) -> unit
    method remove_all_child (c : base_class) -> unit

    method private children : unit -> base_class iterator

    method virtual perform_action unit -> unit

perform_action is supposed to do something with the rendering state and 
call each of it's childrens perform_action methods in turn (unless it's 
a leaf).  base_class is the base class for all objects in a scene graph.

I have narrowed the behaviour of perform_action down to three 
possibilities.  Either it does something before calling it's children, 
it does something after calling it's children or it does something 
before and after calling it's children.  This leads either to one class 
with additional two methods (recode base_class to include pre and post 
ops) or three classes with either a pre or post call or both.  To ensure 
objects don't do extra work I was considering the three class solution 
or a set of classes paramterised by closures which resolve to 
essentially the same thing. e.g.

class type prechild_class =
       inherit base_class

    method virtual pre_op unit -> unit
    method perform_action unit -> unit


(* pre_op_func is a typically a closure and essentially behaves
    like a hook.
class type prechild_class (pre_op_func : unit -> unit) =
       inherit base_class


    method perform_action unit -> unit

Basically pre_op can be overridden to perform the desired function, with 
perform_action calling it before iterating over the children or a 
closure can be provided and called by perform_action.  Is it possible to 
prevent the redefinition of perform_action by a subclass?  If not I can 
live with it, but if there is a way it would serve to enforce the 
intended behaviour of the class.  Namely that it should do what it needs 
to do and call it's children somewhere in perform_action.  One could 
rely on the subclass to encode this behaviour, but it would be very easy 
for programmers to forget this which leads to a violation of what could 
be regarded as a class invariant.

Perhaps a radically different solution is best?  I chose an OO solution 
so that new classes could be trivially added to the system.  It just 
occured to me that the same functionality can be provided with records 
where all the operations are closures.  Pass in the relevant functions 
to a function and get a closure with all the operations of the original 
class.  It's entirely possible I'm over analysing the problem and should 
use something simpler as I've done that before on more than one occassion.

Any advice is welcome.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: