1. docs (OE,Phix) // ? benefits of OOP but simpler

• Posted by _tom (admin) Dec 12, 2016
• 1806 views

There is description from long ago:

Eu|OE|Phix: "achieves many of the benefits of object-oriented programming, yet in a much simpler way."

I need a deeper understanding of what this means. How would you explain this to a person who does OOP programming?

_tom

3. Re: docs (OE,Phix) // ? benefits of OOP but simpler

• Posted by jimcbrown (admin) Dec 12, 2016
• 1829 views

I think this was one of Rob Craig's advertising statements that Jeremy forgot to delete.

There have been some attempts by others to justify this in the past, however. Perhaps they will give you some ideas.

http://openeuphoria.org/forum/m/56324.wc

http://openeuphoria.org/forum/m/14853.wc

5. Re: docs (OE,Phix) // ? benefits of OOP but simpler

• Posted by petelomax Dec 13, 2016
• 1746 views

I'm not convinced it is an entirely bad thing to say. Anyway, regarding the original question:

Off the top of my head I might say:

Object orientation is typically described as encapsulation, inheritance, and polymorphism.

In Phix, encapsulation is achieved simply by placing code in a separate file. Unless you explicitly declare identifiers as global, they are invisible to the outside world, and of course you can modify anything private at any time and nothing else will ever know.

Phix programs are naturally polymorphic. For instance the standard sort() can accept integers, floating points, strings, and/or nested sequences, or any mix of them, without any trouble. In particular you simply do not need umpteen versions of a routine, one that accepts an integer, one a float, yet another one that takes a double, ad nauseum. And for the same reason, there simply is no need for generics, because Phix programs are naturally generic. Try making a list of mixed floats and strings in other programming languages and you will regret it.

In recent years, the latest catchphrase is "favour composition over inheritance", so the lack of any form of inheritance in Phix could even be viewed as an asset, and the ability to store anything at all as an element of a sequence means composition is a given, though it would need to be an index of some kind, rather than the whole thing.

It is fair to say that Phix does not provide any automated form of dynamic despatch, but it is not especially difficult to maintain a table of routine_ids - no more than, say, to declare all the available virtual methods in a separate header file. If you are a strong advocate of object orientated methodology, you may baulk at replacing thing.method() with having to select and include an oo framework and calling vproc(thing,"method",{}). More can and should be done on that front - as much as I may personally believe that it is all hogwash and snake oil, it is in fact a reasonable paradigm and a blanket refusal to add even "oo-lite" features into the core language is not exactly helpful. Note however that it is highly unlikely that Phix will ever enforce oo like some other programming languages do.

Ultimately, of course, if you are already married to the "one true way", whatever that may be in your opinion, no other language will replace the one you already love.

The truth is not that Phix can do all those wacky inside-out things that oop needs, but that it simply does not need them.

Disclaimer: the above may sound too apologetic over the lack of oo features, and we probably don't want that.
Maybe the best strategy for Phix/OE is to catch those who fall off the oo bandwagon and offer them something simpler but just as capable?
Maybe we should stop looking at the grass on the other side and focus on adding more and more capabilities here.

Pete

7. Re: docs (OE,Phix) // ? benefits of OOP but simpler

• Posted by petelomax Dec 13, 2016
• 1737 views

I wouldn't worry about that.
No-one has yet found a concise way to make the case for OOP.
(It takes years and sometimes decades of brainwashing )

9. Re: docs (OE,Phix) // ? benefits of OOP but simpler

• Posted by _tom (admin) Dec 14, 2016
• 1681 views

My working hypothesis for today is:

OOP languages achieve the benefits of Euphoria, at the cost of added complexity and some extra coding. 

I'm beginning to suspect that the best (only) good part of oop is dot notation.

_tom

11. Re: docs (OE,Phix) // ? benefits of OOP but simpler

• Posted by euphoric (admin) Dec 14, 2016
• 1682 views

OOP languages achieve the benefits of Euphoria, at the cost of added complexity and some extra coding. 

ha! Well said. X)

I wonder if Euphoria could use a dot instead of colon for namespace referencing. Then we could call it "object* referencing" and package it as OOP-lite.

datetime right_now = datetime:now()

becomes

datetime right_now = datetime.now()

*Would obviously need to differentiate between the built-in object variable.

13. Re: docs (OE,Phix) // ? benefits of OOP but simpler

• Posted by petelomax Dec 17, 2016
• 1617 views

One other thing I want to say is that (IMO) object orientation was devised in an era preceding such concepts as unit testing, refactoring, and fail fast development, and also largely (totally?) driven by an absolute fear and terror of introducing bugs.

To be fair, between the 60s and early 90s, covering oo from inception to widespread adoption, debugging was often a fairly nasty business.¹

It seems that OpenEuphoria/Phix have, quite naturally and intuitively, the encapsulation necessary to prevent a simple edit from breaking some other completely unrelated part of the system, but perhaps more importantly, addressed the core problem: make debugging easier², rather than jump though all the convoluted hoops of the object orientated paradigm in the vain hope of avoiding it altogether.

In contrast to the dreaded core dump, OpenEuphoria/Phix programs produce a human-readable ex.err file that should contain everything needed (except constants, which are unnecessary 99 out of 100 times, but would not be difficult to add).
Several more modern languages (but not C++) have admittedly greatly improved on the core dump, some even (gasp) show source code line numbers³.

Obviously adding bugs is in no sense a good idea, but it should not be so horrific, and so costly, that you not only impose draconian limits⁴ on what can be edited, but you force all programmers to completely change their way of thinking.

Pete

¹ I could certainly tell you tales of inter-module jumps and variable updates in MicroCobol, and the time(days) they took to fix.
² As a compiler developer, I see a pretty sharp divide between debugging the low-level backend (in assembly), and normal user code (in Phix).
³ Source code line numbers in runtime errors would have been very rare indeed, at the time of the initial widespread adoption of OOP.
⁴ In a roundabout manner by enforcing an object orientated paradigm