GEN Design Patterns in Euphoria 13K Steve Baxter Apr 16/15
An article showing design patterns for procedural languages, and the unique pattern Euphoria 4.0 offers. Euphoria on the largest scales.
http://rapideuphoria.com/design%20patterns%20in%20euphoria.zip
"...This pattern, which I call INTERFACE POLYMORPHISM, addresses the worst case situation: the change of an interface...".
Brilliant.
Yesterday I was programming in LibreOffice Base...
-- This is how you open a form window in Base (without options): oNewFormDocument = ThisDataBaseDocument.FormDocuments.getbyname(sNewDocumentName).open
I don't think that OOP is fun (MS-Access also has its [obj]![obj].obj.method secret object-flags...).
Using Euphoria with INTERFACE POLYMORPHISM pattern I would do it like this:
-- open form, query, table, bottle of vodka, anything (with options): yea = open_window(object x)
That's why I think that adding OOP to Euphoria makes something beautiful - ugly.
Is there any useful pattern that can't be used easily in Euphoria?
Euphoria is ALREADY powerful. But to make it easy to install and to use, it must be distributed as a whole toolkit: Language, Libraries (including GUI development), IDE, Documentation, Setup program for each OS.
Very interesting article. If I understand it correctly:
By using Euphoria's object and sequence data types, all/any procedure or function calls use a single argument. That argument is an object that is likely a sequence which can contain anything,
so the calling argument won't need changing if requirements change, but the called code (eg Java class?) will need to test for the argument contents (sequence length, flags?) of that sequence changing,
to handle previous vs new requirements. Euphoria's automatic garbage collection and lack of pointers helps to make this possible.
On the practical side, it would be a large task to rewrite all Euphoria builtins and standard includes to use this model.
Unlikely to happen without a "benevolent dictator" type of language owner such as Rob Craig before Euphoria went open source...
but if it were done, this (object oriented?) model would seem to lend itself better to program maintainability.
On the practical side, it would be a large task to rewrite all Euphoria builtins and standard includes to use this model. Unlikely to happen without a "benevolent dictator" type of language owner such as Rob Craig before Euphoria went open source... but if it were done, this (object oriented?) model would seem to lend itself better to program maintainability.
INTERFACE POLYMORPHISM pattern is not needed for small building blocks, such as and_bits() or find(); since small building blocks by nature should be simple and efficient.
INTERFACE POLYMORPHISM pattern is useful for designing an application. It lets you work much faster, since you don't have to plan everything very carefully, and it lets you work with a team much easier without worrying too much about a terrible mistake... and it gives your application much longer life - since a big change in the interface makes a big mess, and big mess costs big money. e.g. too many changes in the Linux API might lead some developers to give up their project.
I don't think that Rob Craig is a dictator. I think that he is focused. One must find the correct argument before Rob will agree. I think that's right. (I don't know Rob Craig personally, but many believe that I am my self a dictator... but they are wrong, they simply don't supply a reasonable and practical argument for their ideas).
INTERFACE POLYMORPHISM pattern has nothing to do with Object Oriented Programming. It's a pattern that can be implemented in many languages. But Euphoria is supreme in this case, since Euphoria allows you to use this powerful pattern straight away, while in other languages it might be almost impossible without some kind of a limited intermediate mechanism.
Rob Craig called himself a Benevolent Dictator - all that means is he might listen to other peoples ideas, but the final decision stayed with him.
Yes, that caused focus; Rob would do a lot of testing before releasing a new version, but would not allow things he didn't want, eg "goto".
Anyway, if most non-trivial procedures and functions used interface polymorphism I think it would be a good thing and I would code my own the same way.
But is someone going to rewrite the Euphoria core like this? I doubt anyone has the time unless you get a "benevolent dictator" to own it.
A common mistake is to try to wedge patterns into projects that do not need them. They exist as a practical solution to problems encountered repeatedly in the past.
INTERFACE POLYMORPHISM pattern has the potential to introduce a huge overhead in routines. Obviously this overhead must be avoided in Euphoria's built-ins, and in most library routines. On the other hand, in many big projects this pattern might be a life saver.
In general, you don't need a boat to take a shower, i.e. you don't need a powerful pattern for manipulating strings or for basic I/O.
I believe that the enthusiastic supporters of 'goto' will find it very hard to collect enough compelling reasons for including this command in a language such as Euphoria.
From my point of view, including 'goto' proves one thing: the lack of a clear strategy. Indeed, it's hard (or impossible) to rely on OpenEuphoria while the developers themselves are not sure about their next step.
At least Rob Craig proved maturity, clear and brilliant strategy, and great vision of simplifying the world of programming. And he succeeded. But I cannot say for sure where OpenEuphoria is going.
GitHub