OO getting a bad rap?
Magnus Olsson
It seems object oriented programming has getting a bad rap on this
newsgroup lately. Some posters who are (justly and correctly) upset
about the difficulty of IF programming seems to blame OO for
everything that's difficult with Inform, TADS or Hugo. Sometimes you
get the feeling that people believe there's a world-wide conspiracy of
OO developers, striving to keep IF programming from the masses... :-)
Am I the only one who thinks this is more than a little bit absurd?
True, to somebody who's new to OOP, the OO nature of languages like
Inform adds a little to the conceptual threshold of getting started;
there's a bunch of new terms and concepts to learn. This is especially
true if all your previous exposure to programming is writing small
programs in Basic or Pascal (the non-OO varieties, of course).
But I have a very strong feeling that the true difficulties of IF
programming lie elsewhere. Take a look, for example, at the "typical
newbie questions" posted here by people trying to learn Inform. How
many of the problems on which these posters are stuck are OO-related?
Very few indeed. Most of the problems would remain even if you removed
all traces of OO from Inform.
I have an even stronger conviction that OO, once you've learned the
basic concepts (which isn't difficult at all, provided you're willing
to learn - and IMNSHO an aspiring IF writer who isn't willing to learn
the tools of the trade is like an aspiring novel writer who refuses to
learn to spell), actually makes IF writing *easier*, not more
difficult. That, of course, doesn't mean that Inform is the ultimate
IF language - it very obviously isn't.
And, in fact, the whole situation is rather ironic, since there is
very little OO at all in the Inform libraries. The _language_ is fully
OO, true, but the libraries aren't, and you can in fact write an
entire game in Inform without worrying about inheritance,
encapsulation or abstraction (the three pillars of OO) at all.
So, please, don't blame OO for IF programming being difficult. (I get
the feeling that people who don't understand OO, and who don't even
want to understand it, use it as a catchphrase to lump everything they
don't understand together under one conenient label.)
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
Simon 'Tufty' Stapleton
m...@bartlet.df.lth.se (Magnus Olsson) writes:
> everything that's difficult with Inform, TADS or Hugo. Sometimes you
> get the feeling that people believe there's a world-wide conspiracy of
> OO developers, striving to keep IF programming from the masses... :-)
<snip>
There is. and not just to keep IF programming from the masses. It's
ALL programming that has to be kept from the masses (see below)
> OO, true, but the libraries aren't, and you can in fact write an
> entire game in Inform without worrying about inheritance,
> encapsulation or abstraction (the three pillars of OO) at all.
Inheritance - only passing knowledge on to those who really deserve it
and have done their time coding in C++
Encapsulation - keeping that knowledge within the group of initiates.
Abstraction - making it all look like gobbledegook to the average
joe programmer on the street.
Simon - Grand Master of the Inheritance Hierarchy...
p.s. I could be garrotted with my own keyboard cable for telling you
this - hang on, who's that at the door? <step step step> "No! Not You!
Aaaaaaaghrhrghrgh!" <dull thud>
Andy Wright
Magnus Olsson wrote:
>
> It seems object oriented programming has getting a bad rap on this
> the feeling that people who don't understand OO, and who don't even
> want to understand it, use it as a catchphrase to lump everything they
> don't understand together under one conenient label.)
>
> --
> Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
> ------ http://www.pobox.com/~zebulon ------
> Not officially connected to LU or LTH.
It is not OO in particular that causes the problem - it is programming in
general. True, the phrase "object-oriented" does tend to bring some people
out in a rash, but mostly those who already know some non-OO programming,
and know that the change to object usage requires a different way of thinking.
Non-programmers may see this and regard object-oriented code as even harder
to learn than a "normal" language, when this would not necessarily be the
case when starting from scratch. Inform's object-orientation thus places it
firmly in the "terrifyingly difficult" category of languages, in many people's
eyes.
There's not a great deal that can be done about this. No matter how many
"visual" extensions are made to _any_ language, to write a complicated program
requires a lot of effort in learning that language. Inform is no different
in this respect. It could be made easier to learn, but not by a great deal.
Andy
Neil Brown
At 15:25:32 on Fri, 12 Dec 1997, Simon 'Tufty' Stapleton wrote:
>Inheritance - only passing knowledge on to those who really deserve it
>and have done their time coding in C++
>
>Encapsulation - keeping that knowledge within the group of initiates.
>
>Abstraction - making it all look like gobbledegook to the average
>joe programmer on the street.
I thought it was inheritance, encapsulation and polymorphism. Is
polymorphism the same as abstraction? (I would have thought that
abstraction was, at least partly, covered by encapsulation - at least,
in the definitions I give it is.) And, more importantly, can anyone
provide a decent description of polymorphism in a couple of sentences?
I've been asked to describe it twice now in job interviews, and I'm
always struggling.
Polymorphism - a word that means absolutely nothing, and is only used
within OO in the hope that the jargon will put people off
- NJB
Will Grzanich
Neil Brown wrote:
> And, more importantly, can anyone
> provide a decent description of polymorphism in a couple of sentences?
> I've been asked to describe it twice now in job interviews, and I'm
> always struggling.
I was always told that polymorphism is just the property that a message
can be interpreted in different ways depending on the object receiving
the message. Hmm...what could be an IF-related example? I suppose it's
sort of the way
>hit door
would be interpreted as knocking on it, while
>hit Eddie
would be interpreted as attacking someone.
> Polymorphism - a word that means absolutely nothing, and is only used
> within OO in the hope that the jargon will put people off
That works, too. :)
-Will
--
-= "Soul Brother #1" =- | Check out my out-of-date webpage at
"All you need is love." | www.cen.uiuc.edu/~grzanich!
-John Lennon | Aged like a fine cheese!
Joseph S. Licari
> I have an even stronger conviction that OO, once you've learned the
> basic concepts (which isn't difficult at all, provided you're willing
> to learn - and IMNSHO an aspiring IF writer who isn't willing to learn
> the tools of the trade is like an aspiring novel writer who refuses to
> learn to spell), actually makes IF writing *easier*, not more
> difficult. That, of course, doesn't mean that Inform is the ultimate
> IF language - it very obviously isn't.
I very much agree that OO is actually better for IF programming. I
don't
know Inform or Hugo, but I just love TADS. It is a true OO language
and
is perfect for writing text adventure games. Now, I must admit that I
am
a professional programmer, so of course the programming part is the easy
part for me. The actual designing and writing of the game is another
matter.
However, I can see that non-programmers would have a hard time with
something like TADS since TADS is a full-fledged programming language
and
you really need to know how to program to get the most use out of it.
But I have to agree that they can't blame OO for their problems. It is
like you said, these programming languages are the tools needed to
create
IF, and if a person can't figure out how to use them they should not
blame the tools. I myself have no artistic talent no matter how hard I
try, but it makes no sense for me to blame the brush or the paints or
the
canvas.
Now, you might say, what about something that isn't as difficult to use
but gets the job done? Well, there is always that option but you loose
alot of flexability that way. In my painting example that would be like
using paint-by-numbers. Makes it easier but you lose ALOT of control
over the finished product.
There used to be a tool for creating text adventures called AGT
(Adventure Game Toolkit). I don't know if you can still find it. It
wasn't even close to being OO, and didn't really resemble programming in
the traditional sense in my opinion, but I think it would be alot easier
for non-programmers to use.
Joe Licari
Dan Schmidt
docto...@worldnet.att.net (wHAT yOU lIKE) writes:
| I think a lot of what intimidates people (e.g, me) about OOP is the
| weirdness of the commands in some of the languages. In C++ you get
| things like this:
| 7!&rtw%==lpb.array/#4A655FF,
| which tends to be somewhat off-putting.
Well, OK, but weirdness of commands has nothing to do with whether a
language is object-oriented or not. Eiffel, for example, is about as
object-oriented as a language gets, and it's about the easiest
language to read I've seen.
I hope this doesn't sound offensive, but I get the feeling that a lot
of the people arguing against the object-orientedness of Inform aren't
fully aware of what object-oriented means. At its heart, when you
program in an object-oriented way, you focus on the _objects_ in your
program and how they behave, not on performing one operation after
another. You deal with nouns, not verbs.
Because of the very nature of IF, I find treating the world in an
object-oriented way to make an incredible amount of sense. It's
_nice_ that you can just create a couple of rooms and a couple of
objects and everything just works.
Most of the anti-object-oriented sentiment seem to be more generally
anti-programming sentiment. But I really don't see how you're going
to create a work of IF without programming. You're going to have to
program to make your game at all interesting.
An analogy: I have all sorts of ideas about how I'd like to construct
some really cool buildings. But none of them are going to get off
the ground until I learn something about materials and structural
stability and so forth.
--
Dan Schmidt -> df...@alum.mit.edu, df...@thecia.net
Honest Bob & the http://www2.thecia.net/users/dfan/
Factory-to-Dealer Incentives -> http://www2.thecia.net/users/dfan/hbob/
Gamelan Galak Tika -> http://web.mit.edu/galak-tika/www/
IF
>
>
> There used to be a tool for creating text adventures called AGT
> (Adventure Game Toolkit). I don't know if you can still find it. It
> wasn't even close to being OO, and didn't really resemble programming in
>
> the traditional sense in my opinion, but I think it would be alot easier
>
> for non-programmers to use.
>
Ok, maybe I'm wierd, but I actually found TADS a lot easier to use and
understand than AGT, as well as having TONS more power, and I'd never
programmed a thing in my life. Go figure.
Ian Finley
Trevor Barrie
In article <66rfqh$dvk$1...@bartlet.df.lth.se>,
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>It seems object oriented programming has getting a bad rap on this
>about the difficulty of IF programming seems to blame OO for
>get the feeling that people believe there's a world-wide conspiracy of
>OO developers, striving to keep IF programming from the masses... :-)
>
No. Well, the conspiracy part is reasonable:), but the idea that
object-orientation is a problem in IF languages is just silly.
>I have an even stronger conviction that OO, once you've learned the
>basic concepts (which isn't difficult at all, provided you're willing
>to learn - and IMNSHO an aspiring IF writer who isn't willing to learn
>the tools of the trade is like an aspiring novel writer who refuses to
>learn to spell), actually makes IF writing *easier*, not more
>difficult.
I don't think that's very questionable, to be honest. OOP is about as well
suited to IF as any programming paradigm is likely to be to any problem.
Rancid the Elf
Simon 'Tufty' Stapleton <Si...@No.Bloody.Where> wrote in article
<wzafe6m...@No.Bloody.Where>...
>
> p.s. I could be garrotted with my own keyboard cable for telling you
> this - hang on, who's that at the door? <step step step> "No! Not You!
> Aaaaaaaghrhrghrgh!" <dull thud>
>
Those crazy C++ntologists...
--
Jeremy A.Smith
To reply by Email, change the 'z' in lwtcdz to i
alt.public-relations:alt.eating-toothpast:alt.blow-dry-your-own-head
^^^ The above line of text is merely an obscure signature joke^^^
------------------Advent Calendar Issue - 24 Articles day by day--------
http://www.geocities.com/SoHo/7691
http://www.homeusers.prestel.co.uk/lwtcdi/all/
wHAT yOU lIKE
On Fri, 12 Dec 1997 16:46:12 -0800, Andy Wright <a...@soton.ac.uk>
wrote:
>Magnus Olsson wrote:
>>
>> It seems object oriented programming has getting a bad rap on this
I think a lot of what intimidates people (e.g, me) about OOP is the
weirdness of the commands in some of the languages. In C++ you get
things like this:
7!&rtw%==lpb.array/#4A655FF,
which tends to be somewhat off-putting.
Has anyone written a DLL parser for Visual Basic? :)
Alan Conroy
On Fri, 12 Dec 1997 15:47:59 +0000, Neil Brown
<ne...@this.address.is.fake> wrote:
> And, more importantly, can anyone
>provide a decent description of polymorphism in a couple of sentences?
>I've been asked to describe it twice now in job interviews, and I'm
>always struggling.
>
>Polymorphism - a word that means absolutely nothing, and is only used
>within OO in the hope that the jargon will put people off
There's the technical description which has to do with virtual method
tables, and then there's what it does for you. I define it like this:
polymorphism is the mechanism which allows you to manipulate a set of
classes without having to know any more about them then that they all
descend from a specific ancestor class. Or even more generally, it
allows you to write general code for data types (classes) which aren't
known until run-time.
Personal comment on the whole OOP issue:
It seems that we have the typical spectrum of opinions on OOP
represented in this newsgroup. On one extreme there are the
OOP-haters, on the other side are the OOP-worshippers. In-between are
those of us who realize its potential (both good and bad). Several
years ago, before I know any OOP I viewed it rather incredulously.
People were telling me "OOP will solve all of your programming
problems!" It just sounded too good to be true. When I finally took
the time to understand it, I swung to the opposite extreme - I
actually believed it would solve all of my programming problems.
After programming professionally in OOP languages for a few years, I
discovered that, HORRORS!, OOP actually causes a whole new class of
problems besides solving old ones. I have now swung to the middle.
There are many times when OOP is the best solution. There are times
when it is insane. To those of you on either extreme my advice is to
learn to discern the difference.
Now on a slightly different tangent. Would it be useful for the IF
FAQ to list authoring systems by category? i.e. those which don't use
any algorithmic programming, those which do not use/support OOP, those
which support it but don't require it, and those for which it is
integral. I, personally, would be curious to see a chart making that
comparison. Incidentally, I'm not offering to compile such a list,
but perhaps no one person would need to do all the research...
- Alan Conroy
From the firth, his bark was worse than his bight.
Joseph S. Licari
> Ok, maybe I'm wierd, but I actually found TADS a lot easier to use and
> understand than AGT, as well as having TONS more power, and I'd never
> programmed a thing in my life. Go figure.
I thought AGT was good, mind you, but I found it a little difficult to do
certain things which are very easy (at least in my opinion) to do in TADS. I
also found TADS easier to use in general then AGT.
I think, as I said, that AGT is better for non-programmers. Maybe I am wrong
or you may just be an exception. I definitely agree that TADS has tons more
power then AGT, but I think that in a general case a person with little or no
programming skill would have an easier time getting things done in AGT, but a
person with good programming knowledge can do alot more with TADS then AGT.
Maybe you just have a natural knack for programming.
Joe Licari
Jeff Hatch
Magnus Olsson wrote:
[snip]
> I have an even stronger conviction that OO, once you've learned the
> basic concepts (which isn't difficult at all, provided you're willing
> to learn - and IMNSHO an aspiring IF writer who isn't willing to learn
> the tools of the trade is like an aspiring novel writer who refuses to
> learn to spell), actually makes IF writing *easier*, not more
> IF language - it very obviously isn't.
I agree. OO is much easier to learn than regular programming, imho.
And it applies particularly well to interactive fiction. The hardest
part of OO programming is the creation of new classes, which is seldom
necessary in IF programming.
But I suspect that there are some good writers out there who have poor
spelling, though they're a minority. Editors are wonderful, eh? Too
bad that even the editors don't know the difference between "its" and
"it's." >:-O
-Rúmil
Magnus Olsson
In article <oFyuEOAv...@highmount.demon.co.uk>,
Neil Brown <ne...@this.address.is.fake> wrote:
>At 15:25:32 on Fri, 12 Dec 1997, Simon 'Tufty' Stapleton wrote:
>>Inheritance - only passing knowledge on to those who really deserve it
>>and have done their time coding in C++
>>
>>Encapsulation - keeping that knowledge within the group of initiates.
>>
>>Abstraction - making it all look like gobbledegook to the average
>>joe programmer on the street.
>
>I thought it was inheritance, encapsulation and polymorphism.
You're right.
>Is
>polymorphism the same as abstraction? (I would have thought that
>abstraction was, at least partly, covered by encapsulation - at least,
>in the definitions I give it is.)
Abstraction is mostly covered by encapsulation, but alos by
polymorphism: a polymorphic reference to a Table object, for example,
can be said to abstract the Tableness of different subclasses
RoundTable and so on :-).
>And, more importantly, can anyone
>provide a decent description of polymorphism in a couple of sentences?
>I've been asked to describe it twice now in job interviews, and I'm
>always struggling.
I'm not sure such a definition is very useful. When you're asked to
define an abstract concept in a few sentences, it usually sounds as
goobledegook to anybody who doesn't already know all about the
subject. And reciting such definitions at job interviews usually only
proves that you've memorized the textbooks :-). At least if I were
interviewing, I'd be more impressed if the interviewee could give a
few practical examples of how to use it and when it's good and when
it's bad. (Yes, Virginia, OO is a practical discipline, not a
religion, and its principles can be misapplied).
Magnus Olsson
In article <3491D643...@uiuc.edu>,
Will Grzanich <grza...@uiuc.edu> wrote:
>Neil Brown wrote:
>
>> And, more importantly, can anyone
>> provide a decent description of polymorphism in a couple of sentences?
>> I've been asked to describe it twice now in job interviews, and I'm
>> always struggling.
>
>can be interpreted in different ways depending on the object receiving
>the message. Hmm...what could be an IF-related example? I suppose it's
>sort of the way
>
>>hit door
>
>would be interpreted as knocking on it, while
>
>>hit Eddie
>
>would be interpreted as attacking someone.
Yes, that's a decent example. To concretize a little more: doors and
actors in an IF game share the property of being hittable, although
they don't share very many other properties. So for puproses of
hitting things, you should be able to treat doors and actors exactly
the same.
To concretize even further: Inform is polymorphic in the sense that
you can hit a door by writing the command << Hit barn_door >>, and you
can hit Eddie by << Hit Eddie >>, even though the barn door and Eddie
are quite different objects and react quite differently to being hit
(the barn door isn't very likely to hit back).
Magnus Olsson
In article <66slpr$3...@bgtnsc02.worldnet.att.net>,
wHAT yOU lIKE <docto...@worldnet.att.net> wrote:
>I think a lot of what intimidates people (e.g, me) about OOP is the
>weirdness of the commands in some of the languages. In C++ you get
>things like this:
>7!&rtw%==lpb.array/#4A655FF,
>which tends to be somewhat off-putting.
Actually, that has nothing to do with OO. The root of the weirdness lies
in the non-OO lnaguage C. C++ adds some new syntax, but the only thing
that's really required by OO is the "::" operator that's used to tell
which class something belongs to:
Class::method(foo, bar)
as oppoesed to C's
function(foo, bar)
Of course, C++ templates adds a lot of strangeness to the syntax, but
that's nothing to do with OO in general.
>Has anyone written a DLL parser for Visual Basic? :)
Are people going to recoil in horror and start incanting
counter-curseswhen I say that the features people find so wonderful
about Visual Basic are rather OO, or at least object based?
BTW, Visual Basic is nice for throwing together small GUI apps. It's
not very suitable at all for IF - you could just as well use
QuickBasic in that case.
Irene Callaci
So, for example, if 2 + 2 = 4, and I overload the '+' operator so
that cat + dog = catdog, am I close to showing how polymorphism
works? Does polymorphism allow you to treat different data types
in a similar fashion, without having to know what's going on in
the background? Am I close?
irene
On Sat, 13 Dec 1997 08:27:35 GMT, al...@accessone.com (Alan Conroy)
wrote:
>On Fri, 12 Dec 1997 15:47:59 +0000, Neil Brown
><ne...@this.address.is.fake> wrote:
>
>> And, more importantly, can anyone
>>provide a decent description of polymorphism in a couple of sentences?
>>I've been asked to describe it twice now in job interviews, and I'm
>>always struggling.
>>
>>Polymorphism - a word that means absolutely nothing, and is only used
>>within OO in the hope that the jargon will put people off
>
>There's the technical description which has to do with virtual method
>tables, and then there's what it does for you. I define it like this:
>polymorphism is the mechanism which allows you to manipulate a set of
>classes without having to know any more about them then that they all
>descend from a specific ancestor class. Or even more generally, it
>allows you to write general code for data types (classes) which aren't
>known until run-time.
[snip]
Edan
edh...@eden.rutgers.edu (Edan) writes:
>Edan Harel
>Who can't understand why someone would program a text adventure without an OOP
>language.
Oh god. I just took a look at some posts in the inform for dummies thread.
What a mistake that was. I hope that hornets nest will settle down.
Edan Harel
I think I can even here "flame war, flame war" in the background. ;-)
Graham Nelson
In article <349242d7...@news.accessone.com>, Alan Conroy
<URL:mailto:al...@accessone.com> wrote:
>
> Now on a slightly different tangent. Would it be useful for the IF
> FAQ to list authoring systems by category? i.e. those which don't use
> any algorithmic programming, those which do not use/support OOP, those
> which support it but don't require it, and those for which it is
> integral.
I think this information is already available. In any case I'd
hate it to be thought more significant than it is. In the early
years of the TADS v. Inform wars, the banner of Object Orientation
was frequently held up as a battle-standard (Good grief this
extended metaphor is dying a death, but you get the idea); I don't
really think it affects much more than the perceived cleanliness
of the language, though, in the end. Inform isn't terribly OO,
and the extent to which it is OO is optional. The features are
sometimes nice, sometimes not worth troubling with. That's about
all there is to say, I think.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Magnus Olsson
In article <3492bc78...@news.csupomona.edu>,
Irene Callaci <ical...@csupomona.edu> wrote:
>So, for example, if 2 + 2 = 4, and I overload the '+' operator so
>that cat + dog = catdog, am I close to showing how polymorphism
>works? Does polymorphism allow you to treat different data types
>in a similar fashion, without having to know what's going on in
>the background? Am I close?
Well, what you're describing is overloading, which is in a way the
opposite of polymorphism :-).
But suppose you've overloaded the '+' operator, so you have a collection
of classes that all have such an operator (but nothing in common apart from that), and your language then permits you to write code that works for all
those classes as long as addition is concerned - now, that's a kind of
polymorphism. (As exhibited by template functions in C++).
Another kind of polymorphism is where you require all classes with a
'+' operator to inherit from a common base class AdditionOperand or
whatever, so that integers, floats and strings all are subclasses of
AdditionOperand (this is obviously not possible in C++, but there are
languages where it is in principle possible), and you then write a
function that adds two "things" together like this:
AdditionOperand addtogether(AdditionOperand first, AdditionOperand second)
{
return first + second;
}
(note that this is not possible in C++ as it stands; you'd have to
rewrite it with pointers to be able to return an AdditionOperand, but
again there are languages where this is possible).
Alan Conroy
>So, for example, if 2 + 2 = 4, and I overload the '+' operator so
>that cat + dog = catdog, am I close to showing how polymorphism
>works? Does polymorphism allow you to treat different data types
>in a similar fashion, without having to know what's going on in
>the background? Am I close?
>
>irene
The point of polymorphism is that you dont NEED to override the "+"
operator in some instances. In your example, you could go either way.
A clearer example would be this: you have a general base class called
"numbers". Descended from that are some other classes called
"complex" and "real". Assuming the language you use has a means of
connecting the "+" operator with the "add" method of the base number
class, then you do not need to know whether you are dealing with a
generic number, complex, or real when you code the x + y operation.
At run-time the appropriate add routine is called automatically. This
is especially useful when you write a general-purpose routine which is
passed an instance of a class (such as number), without you needing to
know which particular class at compile-time. Further, your routine
works with any new descendants of the number class that are created
after your work is done.
So, it I haven't confused the issue even more, to address the
question:
>Does polymorphism allow you to treat different data types
>in a similar fashion, without having to know what's going on in
>the background?
The answer is yes, *if* the different data types all descend from a
data type which supports the operation in question.
I recall that when I was learning OOP, it took a while for it to
"click" with me. What helped me was understanding the underlying
mechanism (virtual method tables). But then, I'm overly
detail-oriented. For the average person, I'd suggest looking at LOTS
of examples. Eventually you will have an epiphany and say "OH! NOW I
get it!" You might want to check the local bookstore for a book on
learning some OOP language since they tend to have several of these
examples.
Edan
Hmm, aparently this post of mine went no farther than my school, so I'm
reposting it
edh...@eden.rutgers.edu (Edan) writes:
>Neil Brown <ne...@this.address.is.fake> writes:
>>I thought it was inheritance, encapsulation and polymorphism. Is
>>polymorphism the same as abstraction? (I would have thought that
>>abstraction was, at least partly, covered by encapsulation - at least,
>>in the definitions I give it is.) And, more importantly, can anyone
>>provide a decent description of polymorphism in a couple of sentences?
>>I've been asked to describe it twice now in job interviews, and I'm
>>always struggling.
>A serious explanation of these terms:
>A class is a "template" of some piece of data, that contains rules, variables
>and other things associated with that piece of data. For example,
>we could code a table. A table has the property that you can place
>things on it, move it, stand on it, etc. It has a number of legs, it's
>constructed of wood or metal or whatever.
>An Object is that template where all the information is filled out.
>For example, extending the example I've used, I could create an object
>of a table. It could be made of metal, by 5' by 2', height of 4', have two
>legs, etc.
>Encapsulation (which is not just limited to OOP-ology) the meathod of
>"encapsulating" different parts of the program from each other, some times
>refered to as black-box. This insures that other parts of the program
>do not interfere with the "contents" of the "box" without using some
>already prepared meathods that the encapsulated part has. This is helpful
>in debugging the program, or at least those encapsulated sections.
>Inheratance : The OOP trick of allowing you to reuse code by allowing
>children of classes to gain the same functions as the parent. Some
>programming languages allow multiple parents, but that gets ugly. Thus, for
>example, if you know that all shapes have area, and write a function for
>that, you can then extend that class (shapes) to such things as squares,
>triangles, etc. Perhaps a better example would be triangles. Triangles
>have the rule that they all have three sides. However, there are right sided
>triangles, isosc. triangles, equal. triangles, etc. Thus, when you
>constructed those classes, you would have them extend triangles, cause
>they all share the same rules as triangle does. (Note that you can overwrite
>the rule of the parent if your child behaves differently).
>An Abstract Class:
>This is a class that is not meant to have objects created from it. Mostly
>it's just used for better inheritance. For example, you probably wouldn't
>want to create an object of a triangle if you already have all the
>possibilities of triangles in it's children. Note, though, that had you been
>lacking a child (say you had all but right triangles), you could create an object of triangle and set it's variables to fit those of a right triangle. You
>do lose some of the benefits of OOP, though.
>A Polymorphism.
>This is hard to define, but it's a meathod of passing objects through, and
>being able to refer to that object and use that object without actually
>knowing what it is. I can't come up with a better definition, though. :(
>For example, supposing I had a game and I wanted to shoot any object that
>wanders into a specific room. Now, due to the fact that everyones different,
>they would react in different ways. For example, Spot the WonderDog would
>just run and duck underneath the gun. Mr Titleless would be able to hold his
>shield up high and get past the shooting in the true anonymous fashion.
>The adventurer, would, of course, get shot, unless he was wearing bulletproof
>armour. Thus, when the function for door open was called, it would see
>what object called it (ie, who was entering), and call from it a particular
>function (say OpenDoorResult()) that would tell the object in question to
>print a message saying what happened. It's a little more complicated, but
>that's the general twist. I think.
>Anyone with better (or perhaps more correct) definitions?
>(So, who of you guessed I had a Software Engineering Project due yesterday?)
>Edan Harel
>Who can't understand why someone would program a text adventure without an OOP
>language.
(extra spaces so that it'll post)
FemaleDeer
Well, I've never seen THAT much difference between regular programming and OOP
programming. Maybe, it's just me, because I learned how to program later in
life (after my twenties), so initially it ALL seemed very strange. Therefore,
OOP was no stranger than the rest.
Actually, I would think OOP would be easier for a non-programmer to understand
and it seems ideally suited for IF, since one starts programming with rooms,
which make sense as objects. And, Inform, ISN'T that OOPish (well, it could be
a word.)
FD :-)
------------------------------------------------------------------------------
Femal...@aol.com "Good breeding consists in
concealing how much we think of ourselves and how
little we think of the other person." Mark Twain
Magnus Olsson
In article <19971214213...@ladder01.news.aol.com>,
FemaleDeer <femal...@aol.com> wrote:
>Well, I've never seen THAT much difference between regular programming and OOP
>programming. Maybe, it's just me, because I learned how to program later in
>life (after my twenties), so initially it ALL seemed very strange. Therefore,
>OOP was no stranger than the rest.
In my experience, there's very little difference between
object-oriented and procedural programming. You certainly don't have
to unlearn everything you ever knew about programming to start doing
OOP - that's sheer nonsense.
On the other hand, and I think this is where the confusion comes from,
there's quite a lot of difference between object-oriented *design* and
more "traditional" design methods, such as structured programming. To
design a large OO system from scratch, you have to unlearn some lessons
from your previous life.
What this means is that if the design of the system is fixed on some
abstract level (which in the case of IF is almost always true - the
only Inform game I've ever seen that doesn't conform to Graham's basic
design as encoded in the library is "Space under the window" (not
counting the arcade gams, of course)), then the actual implementation
will not be much different if it's OO or non-OO.
>Actually, I would think OOP would be easier for a non-programmer to understand
>and it seems ideally suited for IF, since one starts programming with rooms,
>which make sense as objects. And, Inform, ISN'T that OOPish (well, it could be
>a word.)
I agree with you on all three counts.
Joe Mason
>Am I the only one who thinks this is more than a little bit absurd?
No. I was going to mention it too.
>True, to somebody who's new to OOP, the OO nature of languages like
>Inform adds a little to the conceptual threshold of getting started;
>there's a bunch of new terms and concepts to learn. This is especially
>true if all your previous exposure to programming is writing small
>programs in Basic or Pascal (the non-OO varieties, of course).
On the other hand, if you don't know ANY programming, then its my opinion that
you'll find yourself much more comfortable with OOP then with traditional
programming. I've now become so used to modelling things in terms of objects
that I have a hard time forcing myself *not* to use OOP concepts - and my
Computer Science assignments this year, which were marked by TA's whose
knowledge of OOP I don't want to trust, show it. It's much more natural to
write an object-oriented program then a procedural one, unless you're already
used to the latter. Maybe not as efficient, but much more natural.
>So, please, don't blame OO for IF programming being difficult. (I get
>the feeling that people who don't understand OO, and who don't even
>want to understand it, use it as a catchphrase to lump everything they
>don't understand together under one conenient label.)
I'm definitely getting that impression.
I think the DM's real failing is the first section, the "here's how you program
part". It definitely isn't as well-written as the rest of the book, and I
think that's where many people are choking. I mean, I was surprised to see it
there at all - I would have assumed that was the kind of thing that you would
already have to KNOW before picking up something like Inform. Now that I see
how many non-programmers are trying to pick up Inform, I see why Graham
included it - but I think a more in-depth look at the basic foundations of OOP
programming (with Inform targeted in particular) is needed. A tutorial would
be perfect.
But the rest of the DM is one of the best I've ever read.
Joe