the OO metaphor

[Peter Andersson]

Hi Chandru,

Thanks for the input! Actually I already use the representation you suggest,
with slight modification. I have a tuple of a Ref and a State record
representing an object and, like in your example, do apply to "invoke" it by
using a type field in Ref (your version is cleaner!). I didn't really think of
this as polymorhism, but I guess that's exactly what it is, as far as
"invokation" is concerned anyway. Deferring functions is the hard part to do
nicely, I guess. I don't know which alternative I would prefer, using funs, an
extended import directive or a modified error handler. I think the most
important thing is that the code is still readable and not too complicated to
debug (like Sean said). Writing a control framework for invoking the objects
with a simple catch to determine if the function is deferred or not, is
tempting. But maybe a mandatory interface function for each class module which
returns a list of the functions the sub class module redefines (and from which
super class) can make the code clearer. Also, perhaps this way the control
framework could do the invokations in a more "controlled" way, rather than
acting upon trapped faults.

For the record, I *have* to say that I only find this interesting in the case I
want to use Erlang to implement something for solving a problem in the domain of
*both* OO and concurrency, like this simulator thing of mine. I *want* to use
Erlang for any type of concurrent implementation, but if the problem is pure OO,
I think I'll choose an OO language to implement the solution in. I find it much
more common, though, that the problems I'm interested in can (and should be)
solved with a "functional approach". In these cases I'm glad to not have to
bother with any OO constructs and overhead. 

Regards

  /Peter


Chandrashekhar Mullaparthi wrote:
> 
> 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.