Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "chris.danx" <chris.danx@ntlworld.com>
To: Caml Mailing List <caml-list@inria.fr>
Subject: [Caml-list] Restricting Method Overriding/Redefinition in Subclass
Date: Sat, 14 Aug 2004 01:03:56 +0100	[thread overview]
Message-ID: <411D56EC.2070301@ntlworld.com> (raw)

Hi,

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
end;;

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 =
    object(self)
       inherit base_class

    method virtual pre_op unit -> unit
    method perform_action unit -> unit
end;;

or

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

    ...

    method perform_action unit -> unit
end;;

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.


Cheers,
Chris

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


             reply	other threads:[~2004-08-14  0:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-14  0:03 chris.danx [this message]
2004-08-14  7:38 ` skaller
2004-08-14 16:28   ` John Prevost
2004-08-14 17:17     ` skaller
2004-08-18 12:04     ` chris.danx
2004-08-18 19:47       ` John Prevost
2004-08-18 22:21       ` skaller
2004-08-16  4:58 Jeff Schultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=411D56EC.2070301@ntlworld.com \
    --to=chris.danx@ntlworld.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox