the OO metaphor

[Peter Andersson]

Ulf Wiger wrote:
> 
> One final point (I may be shooting down my own suggestions, but then
> so be it): Anytime you add something to a programming language, you
> must think carefully about wether it:
> 
> - will make the language harder to learn
> - will shift the focus of the language


I definitely agree with this. 

Maybe it's not such a bad idea to use an interface specification tool from which
you can generate your interface code stubs. Keep your implementation in one
place (no copy-paste) and generate the interface code to it from your specs.
This can enable API reusage and you still get explicit stubs (f()->
OtherMod:f()) which make simple code browsing possible. You can of course still
easily get inconsistency between i/f and implementation, but it might be a lot
easier to control.

I mentioned before that UML has already been used for this in an Erlang project.
I believe it should be possible to make a specification tool that uses a more
logical mapping between the interface specifications and the Erlang
implementation (as far as processes and data types are concerned, for example)
than what you get with UML. The Erlang Interface Specification Tool, EIST,
perhaps!? :-) (Or maybe as part of a more extensive tool based on an event
modelling language).

As far as OO constructs are concerned (we've discussed a few in this thread), I
think these are only interesting (or should I say fun) to discuss as something
that can be implemented in a control framework application for "OO-like"
systems. They should not be proposed as extensions to the Erlang language or
even as OTP components. Both Bjarne and Ulf's latest mails stress the importance
of that!

Regards

  /Peter