Re: OOP in "official" Euphoria
- Posted by Gary Dumer <dumer9354 at WHITE-MARSH.AIM-SMART.COM> Jul 05, 1999
- 517 views
>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.