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>
>
>
>
|
Not Categorized, Please Help
|
|
