RE: Euphoria being OO Survey.
> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> > From: Matt Lewis [mailto:matthewwalkerlewis at yahoo.com]
<lots of snips>
> ==Encapsulation==
> Euphoria already has a form of encapsulation with the 'include' file
> facility. An 'include' file can have private data and private processes,
and
> can force access to its data only via its own routines. However, an
> 'include' file makes a poor 'object' because you can only ever have one
> instance of a specific include file in your program, and you can't really
> pass the include file to routines.
True, although the Euphorian way around this is to store variables in
sequences, using indices to refer to them, rather than pointers (as
something like C++ would do). An additional overhead, yes, but I don't
think it's too draconian. It seems to me that it simply turns the OO
paradigm inside out (one 'member', multiple instances of an object stored in
one container, vs. one instance, multiple members per container). I suppose
one advantage (that I use quite a bit) is that you automatically have all
the instances stored so that searching based on any property is trivial--no
need to worry about adding and deleting instances from a separate storage
container in ctors and dtors.
> > Speaking of which, I've never really understood why OO would
> > make code more reusable. I've often looked at code in the
> archives,
> > to see if I could use something without reinventing the wheel, and
> > most of the time, I can't, because the code simply solves a slightly
> > different problem than what I'm doing. No matter the paradigm, if
> > code doesn't do what you need it to do, you can't reuse it. I don't
> > see the fundamental thing that makes OO more reusable than non-OO.
>
> Partitioning! Typically, procedural code is poorly
> partitioned. A single routine might do many low-level type things.
> And even if it is sort of like what you want, you can't use it because
> you need to change *some* of the little things it does.
But with encapsulation, you often *can't* get at the little routines without
messing with the code, and you still end up changing some of the little
things.
> Using the OO paradigm, coders are encouraged to write tiny
> routines, that
> when combined have the effect required. It is then easier to match new
> requirements be piecing together some tiny routines and
> replacing others.
> The emphasis changes to thinking about interfaces and reusability.
I agree that OO tends to steer you into thinking this way, but if reuse is a
priority, you'll be thinking this way already, whatever your paradigm. One
thing that drives me nuts about OO code (at least when it's C++, but I've
had similar experiences with Delphi) is described very well in this article
(linked from the original oopbad page as "Nuts to OOP"):
http://www.embedded.com/1999/9908/9908feat1.htm
I'm talking about how difficult it can often be to find out the simplest
things about an object, when you have to delve down through several layers
(I also don't care for the C/C++ header/source file methodology, but that's
obviously not an OO issue) of objects/files to find something, and making
sure that you've gone down far enough in the hierarchy, but not too far
(i.e., missed something along the way). And, yes, procedural code can be
just as obfuscating, but I think it tends not to be, at least not in the
same manner.
> But I agree, not all OO code is like this and not all
> procedural code is not like this.
>
> BTW, I'm trying to have Win32lib made up of small (and
> replacable) routines.
I thought v.56 was an interesting approach, though I assume you're going to
do this through namespacing this time around?
> > This is not to say that I think modularity is unimportant,
> > but I don't think that OO has a monopoly on this.
>
> Of course not. Modularity has been recognised as an essential
> coding concept for many decades now. I believe though, that OO encourages
> modularity more than procedural languages do.
Now we're starting to sound like the discussions about forward references
and forcing "good" coding practices that have often been seen here. :)
> > The frequency of discussions doesn't mean anything. The fact
> > that there is rarely a real conclusion or consensus reached says a lot
> > more. Even your own poll has 50% (one vote being mine) saying that OO
should
> > be left out of Euphoria (and only 25% with a strong opinion in
favor)--at
> > the time I write this, anyway.
>
> That's right! It might mean that 50% of the voters don't
> understand OO yet
> 
Well, here's 5% of them that would raise his hand at that!
> Or that people are concerned that if Eu went OO then they
> would have to change their coding practices. Or that it would cause Eu to
slow down.
One concern I have is that (I think I mentioned this before) OO code
generally seems more complex to me, and the simplicity of Euphoria is
important to me. Yes, additional overhead is worrisome, too. I use
machines that range from 233MHz to 1GHz, and that's not likely to change any
time soon, so speed is sometimes critical to me.
Of course, including OO could make some of my projects easier, such as
interfacing with COM or other C++ libs, but I think it would really only be
syntactic sugar (see the thread on Diamond 3.0), which could always be
handled with a preprocessor.
answer = invoke( SomeObject, {SomeClass_m_DoSomething}, {}, {},
DISPATCH_METHOD )
=>
answer = SomeObject.DoSomething()
You'd have to figure out that SomeObject was a SomeClass, and then there's
the problem of passing the variable types. The Euphorian way is certainly
wordier, but also more explicit, I think, which I like--though in many cases
the learning curve is steeper, since really have to know more details about
what you're doing, which isn't always such a bad thing.
Matt Lewis
|
Not Categorized, Please Help
|
|
