Re: OOP in "official" Euphoria

new topic     » topic index » view thread      » older message » newer message

>From: Michael Nelson

>Rob writes that incorporating OOP into Euphoria is not a high priority with
him.  As one of the many >who is working in this area, I agree with him!
The various OOP systems under development have >different
purposes--different strengths and weaknesses.  I love the freedom to use any
I find useful >and to write my own or modify someone else's as I see fit.
Even more, I love the freedom to not use >OOP--and have the overhead of an
OOP system--when the problem doesn't call for it.  This is what I >HATE
about JAVA (which in general I prefer to C++):  It's soooo annoying to have
to define a class >and declare your main program as static void main() just
because the language demands that >everything be an object!

Actually main() is a requirement of C originally. C++ just inherits it from
C. And just because a language contains OOP features doesn't mean you are
required to use them. You can still write a standard non-OOP program in C++
just as you can in Object Pascal from Borland or FreePascal, et. al. And it
doesn't affect the overhead one bit.

>What I might like is an official OOP library and/or a preprocessor (perhaps
based on David Cuny's >|Dot).  This would make OOP readily available but in
no way burden programmers who don't want it >or programs that don't need it.
This would also be less likely to crowd out alternative OOP schemes >that
might be better for particular applications.  And I do think that Euphoria
can benefit from having >multiple OOP models available.  For example, I
think David Cuny's Llama is an excellent specialized >OOP system for dealing
with the Windows API--but some of it's features detract from it as a generic
>OOP system, IMHO.  (This is not a negative criticism of Llama--I think it's
a great piece of work.)

The problem with an external OOP library for Euphoria or any other
interpreted language is that it's just not as fast as if it was implemented
directly within the language itself (hence, my question to Rob). Not to
mention the problems for developers left with the dilema of choosing from 5,
10, 15, or however many different user defined libraries purporting the same
technology, but all implemented differently.

Gary.

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu