[erlang-questions] Re: OOP in Erlang

Tony Arcieri tony.arcieri@REDACTED
Fri Aug 13 22:58:51 CEST 2010


I thought I'd note that what you're describing sounds a *lot* like how Reia
implements immutable objects.  However, Reia does not support
instance-specific behavior. Polymorphism is only offered in the form of
class-based inheritance.

2010/8/12 黃耀賢 (Yau-Hsien Huang) <g9414002.pccu.edu.tw@REDACTED>

> On Wed, Aug 11, 2010 at 9:20 PM, Steve Davis <
> steven.charles.davis@REDACTED
> > wrote:
>
> > things going on
> > here:
> > 1) Data structures and
> > 2) Transformations of data structures.
> >
> >
> I agree. Mandatory features of OOP includes encapsulation, abstraction,
> inheritance, and polymorphism. After reviewing this thread, opinions are
> summarized that including
>    * if we do OOP in Erlang syntax,
>    * if features of OOP are able to be implemented in Erlang,
>    * and if exactly Erlang is an OOP language or OO language.
>
> Now knowledge of OOP is mixture of origin concepts, languages such as
> Smalltalk or Java, and UML modelling methods. Recently I read the book
> "Design Patterns Explained," which hints that OOP/OOD is to treat
> everything,
> including primitive datatypes, as object. And he explained how abstraction
> is
> different from implementation. Then I thought that Erlang treats everything
> as
> function or process, but really? And, Erlang is not toward OOP, so it may
> not
> be OOP-like.
>
> Let's consider how to implement OOP in Erlang, either using Erlang syntax
> or realizing OOP system in Erlang.
>
> Encapsulation: values and functions should be organized as an object
> structure tagged as an object name, belong to some class. It is done by
> Erlang record syntax or as a module, and somehow messages are sent
> to the object or to some member of the structure. Functions in a structure
> may call other fields or functions in other structures. Encapsulation means
> how an object is structured. Any object is generated by following a object
> specification, the class. Object and class are implemented in the same
> way: structure.
>
> Abstraction: it's separated from implementation. Abstraction is done in
> Erlang
> by hot code replacement.
>
> Inheritance: it should be done by taking objects by following
> both superclass
> and subclass specifications and then overriding the superclass object with
> the subclass object, that is to merge base functions into extended
> functions
> effectively. Inheritance shall not be as copying of superclass object, but
> keeping a newest copy of a extended function while keeping the reference to
> its base function. Inheritance semantics shall be consistent.
>
> Polymorphism: it means that different objects, even if they are in the same
> class, may behave separately. It's not a problem because Erlang has this
> feature.
>
> On real OOP, I think that OOP is a feature, and somehow it's the problem
> itself.
> So, when talking about OOP in Erlang, you can have a try to write Erlang in
> OOP style, however, Erlang need not be too OOP-like.
>



-- 
Tony Arcieri
Medioh! A Kudelski Brand


More information about the erlang-questions mailing list