1. RE: Euphoria being OO Survey.
fred at jordah.freeserve.co.uk wrote:
>
> Do you think euphoria for win32 would be better off if it were
> Object-Oriented?
>
> Please take a survey at
> http://logicsoft.pcplayground.com/modules.php?name=Surveys&pollID=2
Here is a website that is devoted to criticism of OOP.
http://www.geocities.com/tablizer/oopbad.htm
Jerry Story
2. RE: Euphoria being OO Survey.
fred at jordah.freeserve.co.uk wrote:
>
>
> ----- Original Message -----
> From: <gertie at visionsix.com>
> To: "EUforum" <EUforum at topica.com>
> Subject: Re: Euphoria being OO Survey.
>
>
> > On 14 May 2003, at 15:06, fred at jordah.freeserve.co.uk wrote:
> >
> > >
> > > > Anyway, is a survey going to do any good?
> > > > "If wishes were fishes...."
> > >
> > > Well, its better than nothing. Maybe it will give pple (Open Euphoria)
> or
> > > RDS some reason to add stuff to the language based on the polls.
> >
> > Polls have not added stuff to RDS before. This is why so many have left
> Eu.
>
> I don't want to leave EU when i know i didn't try to get my points
> across or
> having done nothing out-standing. Eu was fun back in the
> days....NOW....change is needed.
>
> >
> > Kat
> >
> >
> > TOPICA - Start your own email discussion group. FREE!
> >
> >
HMMMM.. the phrase "CHANGE IS NEEDED"
My point that i want to make today is that change should be
'confined'(?) to libraries. then people can choose to accept/modify,
build on it or ignore. if it becomes very popular then add it the main
system.
i appreciate the work that Derek and Judith have done. and Robert C.
without reading windows manuals i can get simpler things in windows
done. but i still prefer 'core' Euphoria.
i debated with myself about changes and overdoing a language over the
years. i dabble with different languages and write at least one program
in each. though i didn't keep my prgrams around, they were for just for
understanding the language.
i like Euphoria because it is close to the pseudo code i use and
executable. i still trying to break bad programming habits.
Euphoria is helping in that regard and letting me be creative.
i keep adding/changing to my lottery program to improve error checking
in it. before releasing it , i want to add a help system.
so it still is not ready to release. sometimes change can cripple
projects until it gets out of hand.
thankyou to all you Eu programmers out there.
later
rudy
lotterywars
3. RE: Euphoria being OO Survey.
> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> > From: "Jerry Story" <jstory at edmc.net>
> > Here is a website that is devoted to criticism of OOP.
> >
> > http://www.geocities.com/tablizer/oopbad.htm
> This man must be a polititian. He can argue a point without
> reasoning. This
> is a very sad example of humanity.
>
> His arguments seem to based on destroying "strawman"
> positions and hearsay!
> No real evidence is actually presented or clinically
> examined. Who are these
> nameless supporters of OO and where are their actual
> quotations? The author
> seems to place many words into many mouths.
>
> I found it mildly amusing that some of his rationale against
> OO could just
> as equally apply to non-OO programming too.
I usually try to stay out of holy-war territory, but since I just installed
linux a few weeks ago, I guess I'm qualified now. :)
Well, he did cite a few references, and I didn't follow many of the links
(many of which are to others' criticisms of OO, and I think at least a few
were to pro-OO pages), but I guess I disagree a bit with your review (can we
lump you in with his OO-fans? :). Much of his point seemed to be exactly
that no one had taken a critical look at the real world benefits and trade
offs associated with OO. Of course he could have posted the name of all the
people he talked about (there were several personal anecdotes about a debate
or an example or whatever), but I thought he made the point several times
that anecdotes shouldn't satisfy anyone. It seemed more of a philosophical
article than a scientific review, and I don't think he was attempting to
misrepresent that.
He admits in several places that OO may be the correct paradigm for some
problems, but not for others. He even says that the most important issue
(at least in the short term) is the individual coder (i.e., how do you
approach and think about programming).
I don't have a degree in CS, and I don't make my living programing, so there
are probably many on this list who have stronger opinions that may or may
not be better thought out, but as a registered Euphoria user, I'll put on my
flame-proof suit and let you know what I think (hopefully I won't set a sad
example for humanity). Derek, I'd be interested in hearing some of your
take (at least briefly) on his rationale that could apply to non-OO
programming.
I definitely agree with him that OO looks great in sound-byte form, but
whenever I've tried to look at or code OO in any real complexity, it's
always left a funny taste in my mouth (how's that for unscientific). I
think a lot of it was the forced hierarchy of OO (at least what I've used or
seen). I tend to approach things from a more set-oriented approach, about
which the author talked a little.
One thing I do like about OO is the concept of polymorphism. Of course this
is really handy in GUI coding, but in a lot of other areas as well.
Win32lib's event handling is probably the best example of that in Euphoria,
and I've used similar things in practically everything I've done.
Personally, routine_id() is my favorite part of the language, since with it
you can write very scalable and reusable code (my matheval lib--used in
EuSQL--is a prime example).
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.
> From: fred at jordah.freeserve.co.uk [mailto:fred at jordah.freeserve.co.uk]
> Thank you Derek for your comments on the issue. It seems most
> people round
> here haven't bothered to code win32 libraries and get ugly
> code + had to
> extend.(bloated).
>
> I was recently looking at the java implementation of Swing
> and i thought
> that was great. I mean,....if you create a basic class eg
> JPanel...you could
> easily extend it my overiding the default methods for
> painting..etc then get
> an Edit Control.
Fair enough. But that doesn't mean that there's not a different way to do
it. Of course, the only thing I know about Swing or JPanels is how to spell
them. It's not obvious to me why an OO implementation is necessarily better
or prettier than a non-OO implementation, though I do admit that GUI's tend
to lend themselves to OO.
> Pple had better try coding GUI libraries then they'll
> understand why its needed for cleaner syntax.
In fact, I'm writing one right now (wxEuphoria), which actually sits on top
of a ton of OO (C++) code, but I don't have your understanding, or perhaps
we don't share the same definition of cleaner syntax. One of the points in
the article was that the author thought problems were often best oriented
around tasks (verbs), as opposed to things (nouns). In general, this fits
my way of thinking. It's often clearer to me when a function sits on its
own than embedding within a class. Of course, this is probably a very
personal preference, but I prefer:
do_it( to_this )
over:
to_this.do_it()
This is not to say that I think modularity is unimportant, but I don't think
that OO has a monopoly on this.
> I think it would be best if we have a PRO euphoria that supports OO or
> similar. Rob, Can't you notice how many times these discussions have been
> repeated? lets have some change...if we cannot get it from RDS, then lets
> team up and get the stones rollin'. OpenEuphoria, and if i could be any
> help, then send me an email..
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.
If you're interested in OpenEuphoria, you can do a search for OpenEu on
Topica and on Sourceforge.
Matt Lewis
4. RE: Euphoria being OO Survey.
> -----Original Message-----
> From: Ken Rhodes [mailto:ken_rhodes30436 at yahoo.com]
> Subject: Re: Euphoria being OO Survey.
>
>
>
> --- Derek Parnell wrote:
>
> " It [OOP] would sure make it [Win32lib] easier to
> extend and have add-ons. Currently, to do
> most new controls you have to know the library's
> internals etc... "
>
> " However, if Euphoria is not going to be OO, then to
> do so for win32 comes at QUIET AN OVERHEAD. "
> -------------------
>
> Considering that an entry level pc now runs with
> a 2gighz cpu and that the Eu2C translator is very
> economically priced - should the OOP "OVERHEAD" still
> be considered prohibitive?
Well I guess everything is relative. What I was trying to say was that
emulating OO using current Euphoria takes significantly (in % terms) more
resources that it would if the OO primitives were built-in to Euphoria.
Also, please note that at no time did I use the word "prohibitive" - this is
something you seem to have placed in my mouth. I have no knowledge whether
it would be prohibitive or not. That is a judgment call for the user,
depending on their machine capabilities and their performance expectations.
I also agree that the new machines one can buy today are so fast that the
1000%+ extra run times for OO emulation can be measured in milliseconds -
not something that we really have to worry about. This must be tempered with
the knowledge that nearly everyone has an older machine than the ones that
are now available. My home machine is a P3 550-MHz that is four years old.
(hmmmm...about time for a new motherboard, me thinks).
--
cheers,
Derek Parnell
--------------------------------------------------------------------
CAUTION - This email and any files attached may contain privileged and
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
--------------------------------------------------------------------
5. RE: Euphoria being OO Survey.
> are now available. My home machine is a P3 550-MHz
> that is four years old.
> (hmmmm...about time for a new motherboard, me
> thinks).
I was gonna say we should take up a collection for
Derek, but then I thought maybe it's best if he
develops on a slower PC because you know he's
optimizing the heck outta the code... ;)
I'm still all for takin' up a collection, though. :)
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
6. RE: Euphoria being OO Survey.
> -----Original Message-----
> From: Matt Lewis [mailto:matthewwalkerlewis at yahoo.com]
> Subject: RE: Euphoria being OO Survey.
>
>
[snip]
>
> I usually try to stay out of holy-war territory, but since I
> just installed
> linux a few weeks ago, I guess I'm qualified now. :)
Yeah, I try to steer clear of these too.
[snip]
I don't really want to critique this author's writings. I don't feel I need
to "defend" OO etc. It was just the manner of many of his arguements,
regardless of the subject, that iritated me.
> One thing I do like about OO is the concept of polymorphism.
Well this is really why so many "discussions" about OO are about - namely
that its very hard to get people, even OO supporters, to agree on exactly
what OO is. So before I continue, I'll state my position - correct or not.
OO is a "noun"-oriented paradigm. We think about things (or objects, if you
will) and their properties, capabilites and behaviours. When approaching a
problem using OO, we try to identify the objects involved and about how they
interact with each other. We solve the problem by coding the appropriate
properties, capabilities and behaviours for the objects involved, that turn
out to satisfy the requirements.
This is quite different to a "verb"-oriented paradigm that has been in use
since the earliest computing days. Commonly called 'Procedural' coding, this
paradigm looks at managing a solution in terms of issuing a sequences of
commands in reaction to the environment. For example a
COBOL/C/Euphoria/Pascal program tends to be a set of instructions that cause
some things to happen when other certain things happen. A cooking recipe has
a similar format.
Another style of coding is "state"-oriented paradigm. These are the
'Functional' languages like Haskell and Lisp. The emphasis here is to
describe what needs to be true for specific states of being. Underlying this
is a sophisticated system that works out how to make all the functional
statements true as events unfold.
There are other paradigms, and mixtures of these main three, present in lots
of programming languages. But to support a claim that language 'X' is an OO
programming language, it must support at least these three concepts:
a) Encapsulation
b) Inheritance
c) Polymorphism
First note that these are concepts - not syntax and not semantics.
Secondly, 'X' might also support other concepts that people might associate
with some existing OO languages. However, these three are mandatory. Any
less than these and its an OO wannabe (and that might not be a bad thing).
==Encapsulation==
The base idea is that a thing's properties and behaviours are bound up in
the same container. Secondary to this is that the only way a thing's
properties can be manipulated is via the thing's own abilites - in other
words, processes outside the thing's container cannot get direct access to
its properties (either to change them or to inspect them).
The form of the container depends on the implementation language; it doesn't
really matter at this point.
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.
==Inheritance==
The idea that you can define a new thing based on another thing's
definition. You only have to detail in the differences.
This is usually used to create more specific things from a generic thing.
Cars, Trains, Bicycles as all specific types of Ground-based
Wheeled-Vehicles
Ships, Yachts, Submarines are all specific types of Water-based Vehicles
Helicopter, Airplane, Glider are all specific types of Air-based Vehicles
Some OO systems allow only single inheritance (you can only use one 'parent'
type to derive a new thing from) and others allow multiple inheritance (a
thing can be derived from any number of 'parent' things).
Army DUK is a specific type of Ground-based AND Water-based vehicle.
Inheritance enabes you to also describe a hierarchy or taxonomy of things.
And using multiple inheritence allows you to describe networks or sets of
classifications.
The benefit of this is that those properties and behaviours that are common
or identical to the parent things do not have to be re-coded.
In GUI systems, there are many opportunities for inheritance.
Euphoria has no built-in support for inheritance.
==Polymophism==
The idea here is that you can have multiple, in scope, routines with the
same name, but with different parameter specifications. And when you
reference the routine name in a call, the language invokes the specific
routine that matches the parameter specification in your call statement.
This means that I can code ...
x = format(1)
x = format(3.1427)
x = format("The rain in spain...")
and the appropriate instance of a format() routine will be called. I no
longer have to write a single format() routine that knows about all
datatypes. I only have to include format() routines for the datatypes I'm
using, and if a new datatype comes along, I need only to include (or write)
its format() routine. No existing code needs to be changed.
Euphoria has no built-in support for polymorphism.
====
When you combine the three concepts, a lot of code become easier to
maintain. Mainly because changes are isolated to small pieces of code.
The OO paradigm is not suited for all situations. Nor is a program required
to be totally OO. And on the other hand, the OO paradigm is better suited to
some situations that other paradigms.
In all these cases, OO can be viewed as a way to organize your code. It is
just a different organization of code than you would tradionally use in a
Euphoria program, for instance. The fact that people have created
fully-functioning OO systems in Euphoria means that OO is not some weird
beast that requires special magic. In fact, the earliest C++ compilers used
to output C code, that was then put through the standard C compiler to
produce the executable. But by not having OO primatives built into Euphoria,
there is a significant overhead in emulating it.
There is nothing inherently evil about OO, even though arguably, some people
have forced the paradigm on inappropriate situations. When I first learned
C++, I tried it out by writing a file conversion utility. Everything was an
object! The program ended up being 10 times larger than it needed to be and
took three times longer to write than if I had just used C. I justified all
this by saying that the next conversion utility needed would be much easier
to write as I now had lots of useful objects defined. And I might have been
right, except there never was a next utility.
> 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.
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.
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.
[snip]
> >
> > I was recently looking at the java implementation of Swing
> > and i thought
> > that was great. I mean,....if you create a basic class eg
> > JPanel...you could
> > easily extend it my overiding the default methods for
> > painting..etc then get
> > an Edit Control.
>
> Fair enough. But that doesn't mean that there's not a
> different way to do
> it. Of course, the only thing I know about Swing or JPanels
> is how to spell
> them. It's not obvious to me why an OO implementation is
> necessarily better
> or prettier than a non-OO implementation, though I do admit
> that GUI's tend to lend themselves to OO.
Just to repeat, not all situations are best handled using OO. Systems that
are, by their very nature, concerned about things and their place in a
hierarchy are good candidates, such as GUI systems.
> > Pple had better try coding GUI libraries then they'll
> > understand why its needed for cleaner syntax.
>
> In fact, I'm writing one right now (wxEuphoria), which
> actually sits on top
> of a ton of OO (C++) code, but I don't have your
> understanding, or perhaps
> we don't share the same definition of cleaner syntax. One of
> the points in
> the article was that the author thought problems were often
> best oriented
> around tasks (verbs), as opposed to things (nouns). In
> general, this fits
> my way of thinking. It's often clearer to me when a function
> sits on its
> own than embedding within a class.
Exactly my point. "noun"-orient verses "verb"-oriented. This is just a way
of organising your code. Whatever works best usually works best 
> Of course, this is probably a very
> personal preference, but I prefer:
>
> do_it( to_this )
>
> over:
>
> to_this.do_it()
Well, this is just syntax. Both these examples could be from an OO language.
There is nothing here to prevent 'do_it()' from being defined in the class
to which 'to_this' belongs, nor is there anything stopping another object
'to_that' also having a routine called 'do_it'.
> 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.
>
> > I think it would be best if we have a PRO euphoria that
> supports OO or
> > similar. Rob, Can't you notice how many times these
> discussions have been
> > repeated? lets have some change...if we cannot get it from
> RDS, then lets
> > team up and get the stones rollin'. OpenEuphoria, and if i
> could be any
> > help, then send me an email..
>
> 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
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.
--
cheers,
Derek Parnell
--------------------------------------------------------------------
CAUTION - This email and any files attached may contain privileged and
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
--------------------------------------------------------------------
7. RE: Euphoria being OO Survey.
> From: fred at jordah.freeserve.co.uk [mailto:fred at jordah.freeserve.co.uk]
> > Matt wrote:
> Matt, think of it this way. You are attempting to write a
> cross-platform GUI library. To make this library readily
> cross-platform you'll have to code your own widgets...eg lists,menus
>
> With time you go to look at all your widgets and see a lot of
> repeated code, then u have to clean it up. Clean up ends up
> introducing bugs, with time, u go to notice that it gets
> annoying trying to modularise your code as it grows
> bigger...etc. With OO, i would create simply a class with eg default
> properties,virtual functions,methods. Say, CWnd Class like in
> MFC, then to all other controls eg when coding the button class. i would
> simply create a class that inherits from the CWnd class, then overide
certain
> methods and have a button control.
Well, frankly, this is an example of a poor engineering process (which I am
often guilty of following). There's no reason why you had to repeat a lot
of code. Some planning up front could have saved that effort. I've found
that over time I've gotten better at the up front planning (a big part of
which is making a conscious decision to do so), and it's a tremendous help.
I've heard many say that OO ("properly" done) often requires *more* up front
design work.
> I dunno how to explain it since i'm not an experienced OO
> user but i think u get what i'm getting at...(i think polymophism).
> Anyway, have u used MFC? See how easy it is? what is better,
> is that, coding ur custom controls is simply involves extending certain
> classes eg CWnd
Have not, and probably will never use MFC. In any case, this is really not
unlike the process of extending, say, win32lib (of which I've done quite a
bit). When I added ListViews and TreeViews, I didn't have to write a whole
new slew of functions that duplicated other things. I simply extended what
was already there and appropriate to the task, and added new functionality
that didn't exist (dealing with ImageLists, for instance).
> Another issue is when you have function names/proc names that
> are similar but different in function...eg Incase you look at win32lib,
> If you look at his setText() proc, u'll notice he uses the if switch
> lots to adjust for it to work for different controls eg
> If class=Menu then
> --code here
> elsif class = window then
> --code here
> end if
>
> wouldn't it be easier to do
> eg in java
> JFrame mw = new JFrame();
> JMenu me = new JMenu();
> mw.setText("blah");
> me.setText("xxg");
> mw.setVisible(1);
How is the java example easier than the following?
constant
mw = create( JFrame ),
me = create( JMenu )
setText( mw, "blah" )
setText( me, "xxg" )
setVisible( mw, 1 )
>From the library standpoint, why is the if switch so wrong? It simply
brings the code to one place, which is probably a plus for maintenance.
Also, many of the functions in win32lib end up sending a very similar
message to some control, but having all of it in one place simplifies things
a bit (e.g., only need to allocate a string in one place).
If you don't like the if switch, you can use routine_id() to add arbitrarily
large numbers of routines (which can, of course, be located anywhere) using
an associative list:
ix = find( control_type, valid_control_types )
call_proc( control_routines[ix], {})
Matt Lewis
8. 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
9. RE: Euphoria being OO Survey.
One thing...
OO explanations are always, ALWAYS demonstrated with things like "Vehicle",
and "Car" and "Truck" children....
Nobody makes programs about Trucks and Cars unless they are programming a
simulation, or a database with objects in it that may be one or t'other. Can
anyone give an example of what sort of objects (one parent, 2 or more
children) would fit the bill for a *normal* sort of project... ie not one of
the above examples, and demonstrate the use of inheritance?
I don't see any advantage to using object oriented anything... Even things
like making sure persistent variables stay private is easy... just put them
& their procedures into a separate include file - probably a good idea
anyway. And things like data protection are handled by default in Euphoria -
no pass-by-reference.
I've heard plenty of theoretical situations where the paradigms of OO shine.
However, I'm yet to see a real-world (read: useful) example that could
demonstrate anything swaying me towards OO.
=====================================================
.______<-------------------\__
/ _____<--------------------__|===
||_ <-------------------/
\__| Mr Trick
>From: Derek Parnell <ddparnell at bigpond.com>
>Reply-To: EUforum at topica.com
>To: EUforum <EUforum at topica.com>
>Subject: RE: Euphoria being OO Survey.
>Date: Fri, 16 May 2003 16:34:51 +1000
>
>
> > -----Original Message-----
> > From: Matt Lewis [mailto:matthewwalkerlewis at yahoo.com]
> > Sent: Friday, 16 May 2003 3:22 AM
> > To: EUforum
> > Subject: RE: Euphoria being OO Survey.
> >
> >
>[snip]
>
> >
> > I usually try to stay out of holy-war territory, but since I
> > just installed
> > linux a few weeks ago, I guess I'm qualified now. :)
>
>
>Yeah, I try to steer clear of these too.
>
>[snip]
>
>I don't really want to critique this author's writings. I don't feel I need
>to "defend" OO etc. It was just the manner of many of his arguements,
>regardless of the subject, that iritated me.
>
> > One thing I do like about OO is the concept of polymorphism.
>
>Well this is really why so many "discussions" about OO are about - namely
>that its very hard to get people, even OO supporters, to agree on exactly
>what OO is. So before I continue, I'll state my position - correct or not.
>
>OO is a "noun"-oriented paradigm. We think about things (or objects, if you
>will) and their properties, capabilites and behaviours. When approaching a
>problem using OO, we try to identify the objects involved and about how
>they
>interact with each other. We solve the problem by coding the appropriate
>properties, capabilities and behaviours for the objects involved, that turn
>out to satisfy the requirements.
>
>This is quite different to a "verb"-oriented paradigm that has been in use
>since the earliest computing days. Commonly called 'Procedural' coding,
>this
>paradigm looks at managing a solution in terms of issuing a sequences of
>commands in reaction to the environment. For example a
>COBOL/C/Euphoria/Pascal program tends to be a set of instructions that
>cause
>some things to happen when other certain things happen. A cooking recipe
>has
>a similar format.
>
>Another style of coding is "state"-oriented paradigm. These are the
>'Functional' languages like Haskell and Lisp. The emphasis here is to
>describe what needs to be true for specific states of being. Underlying
>this
>is a sophisticated system that works out how to make all the functional
>statements true as events unfold.
>
>There are other paradigms, and mixtures of these main three, present in
>lots
>of programming languages. But to support a claim that language 'X' is an OO
>programming language, it must support at least these three concepts:
>a) Encapsulation
>b) Inheritance
>c) Polymorphism
>
>First note that these are concepts - not syntax and not semantics.
>Secondly, 'X' might also support other concepts that people might associate
>with some existing OO languages. However, these three are mandatory. Any
>less than these and its an OO wannabe (and that might not be a bad thing).
>
>==Encapsulation==
>The base idea is that a thing's properties and behaviours are bound up in
>the same container. Secondary to this is that the only way a thing's
>properties can be manipulated is via the thing's own abilites - in other
>words, processes outside the thing's container cannot get direct access to
>its properties (either to change them or to inspect them).
>
>The form of the container depends on the implementation language; it
>doesn't
>really matter at this point.
>
>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.
>
>==Inheritance==
>The idea that you can define a new thing based on another thing's
>definition. You only have to detail in the differences.
>
>This is usually used to create more specific things from a generic thing.
> Cars, Trains, Bicycles as all specific types of Ground-based
>Wheeled-Vehicles
<snip>
>
>
>
