Browse thread
[Caml-list] Restricting Method Overriding/Redefinition in Subclass
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@u...> |
| Subject: | Re: Re: [Caml-list] Restricting Method Overriding/Redefinition in Subclass |
On Sun, 2004-08-15 at 02:28, John Prevost wrote: [structural subtyping] > At this point, you may be wondering "Why is O'Caml like this? My stupid answer is "because its correct". The kind of subtyping by subclassing used in Java and C++ is really awkward to use. Basically the problem is, to extend the capabilities of your object heirarchy, you inevitably have to add a new method to a base class, or equivalently derive from an extra base class containing it -- which breaks the principle of encapsulation that is supposedly the foundation of object orientation: such breakage is said to be invasive, and it contravenes the Open/Closed principle (see Meyer). This isn't the case for structural subtyping, where A is a subtype of B simply if it is one -- you don't have to derive A from B -- which might not even exist at the time you write A. This means you can write algorithms that work on sets of classes sharing some properties (such as a collection of methods) AFTER you define the classes without invading the class definitions -- in Java or C++ you'd have to add inheritance specifications to make this work. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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