the OO metaphor
Chandrashekhar Mullaparthi
Chandrashekhar.Mullaparthi@REDACTED
Wed Nov 29 12:35:08 CET 2000
I think polymorphism can be implemented by modelling objects using records,
and a field in the record specifying the module which implements the
interface exported by the object.
-record(object, {interface, instance}).
-record(rectangle, {length, width}).
-record(circle, {radius}).
To create an object of type rectangle - you would write
#object{interface=rectangle, instance=#rectangle{length=2, width=3}}.
To create a circle -
#object{interface=circle, instance=#circle{radius=4}}.
So if you have a shape and want to draw it:
Shape#object{interface=I, instance=Obj},
Action=draw,
apply(I, Action, [Obj]) or
apply(I, Action, [Obj, <Other params>]) as the case may be.
Now if you have a base class called shape - you can call functions defined
in it from your "derived class implementation". You can even store an
instance of your "base class object" in the instance of your "derived class
object" like..
-record(rectangle, {length, width, shape}).
RTTI can be supported by exporting a function called type from the interface
module!!
As for being able to override functions in other modules, maybe the existing
"-import" directive can be extended.
-module(my_module).
-import(Mod, Func/Arity).
will import all clauses of the specified function. If this module defines a
function with the same name and arity, that will "override" the
implementation of the imported function. And in case none of the clauses in
the "overridden" version match the call, it can be routed to Mod:Func(...).
This will also cover the case where no implementation is provided for
imported functions by my_module.
-import(Mod, all). will import all functions from module Mod.
Chandru
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
More information about the erlang-questions
mailing list