[Inform-OO] The Light Dawns...
David A. Cornelson
After all of my blathering over how difficult object-orientation is, I think
I finally get it. I picked up a Java book, Bruce Eckel's, Thinking In Java,
and read it pretty throroughly, or at least the important bits. I've started
rewriting one of my games (Inform) and have probably already saved ten pages
of code using the knowledge that I gained from the Java language.
Lights are going off all over the place and instead of constantly saying to
myself, "Okay, where do I handle THIS little piece of logic", I'm thinking,
"This goes right HERE!", and it's all making a lot more sense.
I humbly apologize to all for my stubbornness, although now I'm going to be
asking more oo questions, so what's worse, bitching about oo, or bothering
you about oo? (:
Jarb
Joyce Haslam
You can bother me with it till the cows come home, if you can make it make
sense.
Joyce.
--
Joyce Haslam
dljh...@argonet.co.uk
Doeadeer3
>Lights are going off all over the place and instead of constantly saying to
>myself, "Okay, where do I handle THIS little piece of logic", I'm thinking,
>"This goes right HERE!", and it's all making a lot more sense.
>
>I humbly apologize to all for my stubbornness, although now I'm going to be
>asking more oo questions, so what's worse, bitching about oo, or bothering
>you about oo? (:
>
>Jarb
OO IS nifty, isn't it? Once the light dawns one tends to fall in love with it.
Feel free to fire away your questions. Inform isn't THAT OOish (hmm, not a
word, but you get the idea). It only has about 5 or so REAL OO type of
commands, so I doubt you will need to ask that much. (The main "trick" is
writing your own code in an OO manner, i.e., using the convience of objects to
dump most pertinent code in them. In fact, the Inform library itself, (the h
files), could be written in much more of an OO way. I suspect that is because
the increasing OO development of Inform came AFTER the first library). But,
glad you have "seen the light".
Doe :-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Adam J. Thornton
Doeadeer3 <doea...@aol.com> wrote:
>OO IS nifty, isn't it? Once the light dawns one tends to fall in love with it.
>Feel free to fire away your questions. Inform isn't THAT OOish (hmm, not a
>word, but you get the idea). It only has about 5 or so REAL OO type of
>commands, so I doubt you will need to ask that much. (The main "trick" is
>writing your own code in an OO manner, i.e., using the convience of objects to
>dump most pertinent code in them. In fact, the Inform library itself, (the h
>files), could be written in much more of an OO way. I suspect that is because
>the increasing OO development of Inform came AFTER the first library). But,
>glad you have "seen the light".
Can someone explain something to me?
I see what Doe means here; that if you want Taking the Mogelschnitzer to do
something radically different from Taking Anything Else in your game, you
should override Take in the Mogelschnitzer methods, not have a special case
in your Take verb code to see if the direct object is Mogelschnitzer.
But doesn't the rest of OO--and even this, too, if you think about it--just
boil down to using an Abstract Data Type model in your code and forcing
yourself to go through your access functions to get to that data?
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Andrew Plotkin
> In article <6r9sfa$k...@newsops.execpc.com>, "David A. Cornelson"
> <dcorn...@placet.com> writes:
> >Lights are going off all over the place and instead of constantly saying to
> >myself, "Okay, where do I handle THIS little piece of logic", I'm thinking,
> >"This goes right HERE!", and it's all making a lot more sense.
> OO IS nifty, isn't it? Once the light dawns one tends to fall in love with it.
> Feel free to fire away your questions. Inform isn't THAT OOish (hmm, not a
> word, but you get the idea). It only has about 5 or so REAL OO type of
> commands, so I doubt you will need to ask that much.
Actually, I disagree. There's lots of OO in Inform (plus libraries.)
The fun part is that there are about five or six different *mechanisms* to
do object-oriented design -- added at different times, for different
purposes, with different limitations and degrees of hackishness and
concepts of "object". All different, all twisty.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Andrew Plotkin
> Can someone explain something to me?
> I see what Doe means here; that if you want Taking the Mogelschnitzer to do
> something radically different from Taking Anything Else in your game, you
> should override Take in the Mogelschnitzer methods, not have a special case
> in your Take verb code to see if the direct object is Mogelschnitzer.
> But doesn't the rest of OO--and even this, too, if you think about it--just
> boil down to using an Abstract Data Type model in your code and forcing
> yourself to go through your access functions to get to that data?
I regard ADT and OO as different. More accurately, OO = ADT + inheritance.
Data abstraction is when you divide your data into objects, and each
type of object has a well-defined interface, and you always manipulate
the object through its interface. Promises and guarantees.
Object orientation is when some of your types are derived from other
types. A derived type has the same interface as the parent type, with
additions. (Or changes, but the scope of the changes are known to the
parent, so you might as well call them additions.)
An even higher-level definition which I like: ADT is what lets other
people reuse your code. OO is what lets *you* use *other* people's code
*even if it hasn't been written yet.*
Adam J. Thornton
Andrew Plotkin <erky...@netcom.com> wrote:
>An even higher-level definition which I like: ADT is what lets other
>people reuse your code. OO is what lets *you* use *other* people's code
>*even if it hasn't been written yet.*
I thought that was "a well-specified interface."
Your point about inheritance is well taken, though.
Joe Mason
Adam J. Thornton <ad...@princeton.edu> wrote:
>
>But doesn't the rest of OO--and even this, too, if you think about it--just
>boil down to using an Abstract Data Type model in your code and forcing
>yourself to go through your access functions to get to that data?
Nope. It's a conceptual thing - I don't associate objects with data, I tend
to associate objects with... well, depends. In an IF game, objects are
objects. Otherwise, I tend to think in terms of both "data objects" (ie.
this guy's in charge of maintaining the window list) and objects which are
in charge of tasks. (This guy's the event handler, and is in charge of
dispatching messages to all the windows.) Now, the event handler is a data
object, too - it stores the event queue - but it has much more specialized
behaviour then an ADT. An ADT would simply be able to hand off the next event
in the queue to an external function, which would then decide what to do
with it, whereas the event handler object contains ALL the code that passes
events around.
Of course, there are a couple of ways of looking at the desing. For instance,
is it more correct to say that EventHandler "is a Queue", in which case you
would make it a subclass of Queue with extra methods to do specialized event
stuff, or is it better to say that EventHandler "has a Queue", meaning it
maintains a pointer to a separate event Queue, and asks that queue for the
next event each time it processes it. (And I'm not really up on the most
efficient ways to handle event queues and such, which makes me wonder why
I picked it for an example.)
For a more I-F related example, consider implementing an NPC's memory: you
have a number of conversation topics, and for each one you have to store
the number of times the player has asked about it. An obvious case for a
Table ADT with the topics as keys. If you were coding in a non-OO manner,
you'd have a table structure for the sole purpose of maintaining this data,
and the NPC would be coded in separate routines to make use of it. An
NPC object would inherit the behaviour it needs to maintain this table from a
generic Table class, and then extend on it to do all the specialized
processing it requires. For instance, routines that calculate how often
related topics have been asked about, in order to adjust the NPC's suspicion
levels...
The point is, if his object needs special behaviour that wouldn't be
appropriate for a general ADT, you can still encapsulate it within the
object.
Joe
Magnus Olsson
Doeadeer3 <doea...@aol.com> wrote:
>In article <6r9sfa$k...@newsops.execpc.com>, "David A. Cornelson"
><dcorn...@placet.com> writes:
>
>>Lights are going off all over the place and instead of constantly saying to
>>myself, "Okay, where do I handle THIS little piece of logic", I'm thinking,
>>"This goes right HERE!", and it's all making a lot more sense.
>>
>>asking more oo questions, so what's worse, bitching about oo, or bothering
>>you about oo? (:
Hear, hear!
(And IMHO bitching about anything is far worse than "bothering" (in
the sense of asking questions) us about it).
>OO IS nifty, isn't it? Once the light dawns one tends to fall in love with it.
>Feel free to fire away your questions. Inform isn't THAT OOish (hmm, not a
>word, but you get the idea). It only has about 5 or so REAL OO type of
>commands, so I doubt you will need to ask that much.
As I'm sure David has discovered :-), OO is not so much about learning
a few new "commands", but of organizing one's code and thoughts - it's
a matter of design, not of syntax. (And to preclude *that* debate from
rasing its ugly head again, by "design" I do *not* mean the various
bureaucratic formalities that sometimes seem designed only to stifle
the programmers' creativity).
> (The main "trick" is
>writing your own code in an OO manner,
Indeed.
>i.e., using the convience of objects to
>dump most pertinent code in them.
Well, I'd formulate it in a slightly more positive manner: you make it
sound as if OO was a way of sweeping the dust under the carpet, while
it's really a different way of organizing your cleaning :-).
>In fact, the Inform library itself, (the h
>files), could be written in much more of an OO way. I suspect that is because
>the increasing OO development of Inform came AFTER the first library).
Your suspicions are confirmed by the available evidence :-). As I've
stated a couple of times, IMO the greatest weakness of the Inform
library is its almost total lack of OO (or, if you're not sold on OO
yet, its lack of modularity and modifiability).
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Magnus Olsson
Of course; always glad to be of service to the community!
>I see what Doe means here; that if you want Taking the Mogelschnitzer to do
>something radically different from Taking Anything Else in your game, you
>should override Take in the Mogelschnitzer methods, not have a special case
>in your Take verb code to see if the direct object is Mogelschnitzer.
>
>But doesn't the rest of OO--and even this, too, if you think about it--just
>boil down to using an Abstract Data Type model in your code and forcing
>yourself to go through your access functions to get to that data?
Well, OO can be viewed as an extension of the ADT model, with the difference
that the operations on an ADT (its member functions/methods/messages) are
syntactically kept together with the data.
However, there's more to OO than that: inheritance and polymorphism
are even more important (especially in languages such as TADS that
don't have any data hiding), and go beyond the ADT model.
In fact, I'd say that for smallish projects like a typical Inform or
TADS game, information hiding is relatively less important; the great
advantage of using an OO language for IF and other simulations is that
you can, say, implement the King's Magical Throne by inheriting from
an ordinary chair, and have the program automatically treat it as a
chair for all purposes where you haven't changed its behaviour
(polymorphism).
David Given
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
[...]
>Your suspicions are confirmed by the available evidence :-). As I've
>stated a couple of times, IMO the greatest weakness of the Inform
>library is its almost total lack of OO (or, if you're not sold on OO
>yet, its lack of modularity and modifiability).
I heard that someone's writing a real OO library. Can anyone confirm or
deny this? If so, how's it getting on? At some point I'm planning to write
a piece of IF, and haven't really been looking forward to getting to grips
with the standard library.
Yes, I *know* I could use ALAN or TADS or such like. But I have fond
memories of Z-machine games and Inform and really like the idea of
stepping into the opcodes of the giants.
--
+- David Given ----------------+
| Work: d...@tao.co.uk | Power corrupts. Absolute power is
| Play: dgi...@iname.com | kind of neat.
+- http://wiredsoc.ml.org/~dg -+
Andrew Plotkin
> Andrew Plotkin <erky...@netcom.com> wrote:
> >An even higher-level definition which I like: ADT is what lets other
> >people reuse your code. OO is what lets *you* use *other* people's code
> >*even if it hasn't been written yet.*
>
> I thought that was "a well-specified interface."
That's what I meant by "letting other people reuse your code."
What I mean by "you using other people's code" is, you can write code now
which uses a class of objects, and people can *later* come along and write
more objects which work with your existing program. Not just other
implementation of the same interface, but an extended interface.
The usual example is a view object. You write a display system that
displays objects of class View. You handle redraw events, resize events,
key and mouse events, etc. Then you're done. Other people can write
GIFView, TextWidgetView, CompassRoseView, all inheriting from your View
class (with added or changed behavior.) These new types all work with
your display system, even if you've retired and moved to Tahiti.
Adam J. Thornton
Andrew Plotkin <erky...@netcom.com> wrote:
>What I mean by "you using other people's code" is, you can write code now
>which uses a class of objects, and people can *later* come along and write
>more objects which work with your existing program. Not just other
>implementation of the same interface, but an extended interface.
>The usual example is a view object. You write a display system that
>displays objects of class View. You handle redraw events, resize events,
>key and mouse events, etc. Then you're done. Other people can write
>GIFView, TextWidgetView, CompassRoseView, all inheriting from your View
>class (with added or changed behavior.) These new types all work with
>your display system, even if you've retired and moved to Tahiti.
Ah. OK. And that, obviously, requires inheritance. Gotcha.
All becomes clear.
Too bad Java's performance is so sucky and I haven't yet been able to get
Toba to build on my system.
David A. Cornelson
>In article <199808180139...@ladder03.news.aol.com>,
>Doeadeer3 <doea...@aol.com> wrote:
>>In article <6r9sfa$k...@newsops.execpc.com>, "David A. Cornelson"
>><dcorn...@placet.com> writes:
>>
>(And IMHO bitching about anything is far worse than "bothering" (in
>the sense of asking questions) us about it).
Admittedly, I come off wrong sometimes....working on that...
>As I'm sure David has discovered :-), OO is not so much about learning
>a few new "commands", but of organizing one's code and thoughts - it's
>a matter of design, not of syntax. (And to preclude *that* debate from
>rasing its ugly head again, by "design" I do *not* mean the various
>bureaucratic formalities that sometimes seem designed only to stifle
>the programmers' creativity).
All I know is that I had these huge blocks of code for 4 nearly identical
locations, the sidewalk. I had Sidewalk1, Sidewalk2, Sidewalk3, and
Sidewalk4, each al least a page long in code. Now I have a Class Sidewalk
with code about a page long, and four objects of that class with not one
thing after the name and description. I've also thrown out several
attributes and globals that I'd needed to keep track of things that I
realize now do not need keeping track of.
The "self" identifier is what I really had a hard time understanding and I
think Bruce Eckel's explanation of Polymorphism was what finally triggered
my leaps in thinking. It's free on the web at http://www.bruceeckel.com if
anyone is interested.
I do have a questions though, I have a situation where a couple of
properties overlap, say a couple of compass direction properties. Outside of
writing an external function to handle this code, is there any other way to
bring the code into the object itself without duplicating it? Wait, I
suppose I could create another 'property' which is just another method and
call object.property(argument) from within the other two property/methods?
Is that right? After all, a property is a method is a function.
Jarb
Daryl McCullough
>An even higher-level definition which I like: ADT is what lets other
>people reuse your code. OO is what lets *you* use *other* people's code
>*even if it hasn't been written yet.*
To me, that's the interesting thing about OO code; it completely
changes what it means for code to be "correct". In old-fashioned
structured languages, like Pascal, the meaning of a program is
compositional: if you understand the meaning of "do P" and "do Q",
then you understand the meaning of "do P then do Q" and "if condition
then do P otherwise do Q", etc.
On the other hand, as you say, an OO program can make calls on
programs that are not yet written. One piece of code may call
an operation such as "display", "save", "restart", or whatever,
whose meaning has not yet been determined, since each new class
is free to reimplement these operations in arbitrary ways (only
restricted by the signature).
It seems to me that OO programming relies greatly on
programmers' shared intuitions about the meaning of
functions, so that reimplementations don't violate
those intuitions. (Of course, there is the theoretical
possibility that adequate documentation can make up
for a lack of shared intuition.) In this way, it seems
to me that OO programming is much more of a human,
social activity than traditional programming is.
That's why I hate it.
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Andrew Plotkin
> I do have a questions though, I have a situation where a couple of
> properties overlap, say a couple of compass direction properties. Outside of
> writing an external function to handle this code, is there any other way to
> bring the code into the object itself without duplicating it? Wait, I
> suppose I could create another 'property' which is just another method and
> call object.property(argument) from within the other two property/methods?
That would work. I usually write an external function. It's entirely a
matter of taste.
okbl...@usa.net
I knew where you were going with this, and I think you're wrong. :-)
> On the other hand, as you say, an OO program can make calls on
> programs that are not yet written. One piece of code may call
> an operation such as "display", "save", "restart", or whatever,
> whose meaning has not yet been determined, since each new class
> is free to reimplement these operations in arbitrary ways (only
> restricted by the signature).
The problem lies in "meaning has not yet been determined". Well-designed
objects place specific restrictions on what can be done or not done and still
be considered a correct use of the method. There are also gray areas, and
huge areas of non-specified possible uses, all of which the object code
should funtion under.
Does it make bad code possible? Sure. Is that code potentially any worse
than that made possible by structured/other techniques? Maybe. Is it wildly
useful? Unquestionably, and there may be a connection between its usefulness
and its susceptibility to abuse.
But until a computer can figure out what an operation *means* absolutely =any=
form of extensibility can lead to the abuse you describe.
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Graham Nelson
> OO IS nifty, isn't it? Once the light dawns one tends to fall in love with it.
OO has instant appeal. Reading your first book about it is like
going to a revivalist meeting. Those who feel lost sink to their
knees and sob for the joy of being forgiven and welcomed, and
for all those lovely certainties.
The week after that, you try to write your first slightly-involved
bit of OO code. You notice that, for instance, you are trying to
code a bird which is summoned by a whistle. So -- where does the
code for this go? Is it behaviour of the bird, or of the whistle,
or of the whistle-blower? Which object should be rewritten? Hmmm...
And so the doubts begin to set in. Eventually, you're left with
just the vague, humanist ethics of the religion in question, and
none of the dogma.
> Feel free to fire away your questions. Inform isn't THAT OOish (hmm, not a
> word, but you get the idea). It only has about 5 or so REAL OO type of
> commands, so I doubt you will need to ask that much. (The main "trick" is
> writing your own code in an OO manner, i.e., using the convience of objects to
> dump most pertinent code in them. In fact, the Inform library itself, (the h
> files), could be written in much more of an OO way. I suspect
(correctly)
> that is because
> the increasing OO development of Inform came AFTER the first library). But,
> glad you have "seen the light".
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
David Given
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
[...]
>OO has instant appeal. Reading your first book about it is like
>going to a revivalist meeting. Those who feel lost sink to their
>knees and sob for the joy of being forgiven and welcomed, and
>for all those lovely certainties.
>
>The week after that, you try to write your first slightly-involved
>bit of OO code. You notice that, for instance, you are trying to
>code a bird which is summoned by a whistle. So -- where does the
>code for this go? Is it behaviour of the bird, or of the whistle,
>or of the whistle-blower? Which object should be rewritten? Hmmm...
>
>And so the doubts begin to set in. Eventually, you're left with
>just the vague, humanist ethics of the religion in question, and
>none of the dogma.
Nicely put.
Given your example, I'd say that since the whistle and the bird are
inherently linked, then the whistle would have to contain a pointer to the
bird internally. When you blow the whistle (method on the whistle), it
would send a message to the bird to tell it to go to the whistle (or the
player).
In a bit more detail, I'd implement a method on the bird that made it fly
to a certain location. The whistle would then call this method to make the
bird go to the same location the whistle's in (or the whistle's holder).
Special cases --- for example, if the player blows the whistle, the bird
perches on its shoulder --- would be implemented in bird.goto(). This also
gives you, for free, most of the functionality required for a twitch
routine for the bird.
OO is a bit difficult to define. Basically, my perception of it is that it
is a particular way to address a programming problem that may or may not
be useful. I find it useful in cases where the problem reflects a
real-world case; IF, UI widgetry, and so on. I find it monumentally
useless where the problem *doesn't* reflect a real-world case. Take a look
at the Java gibberish in process management and program start-up.
--
+- David Given ----------------+
| Work: d...@tao.co.uk | He who hesitates is last.
| Play: dgi...@iname.com |
+- http://wiredsoc.ml.org/~dg -+
Daryl McCullough
>
>In article <6rc4ro$3...@drn.newsguy.com>,
> da...@cogentex.com (Daryl McCullough) wrote:
>>
>> That's why I hate it.
>>
>
>I knew where you were going with this, and I think you're wrong. :-)
I'm wrong? I actually *like* OO?
Oh, you're right! Actually, I was just kidding about hating OO,
but I wasn't kidding about OO programming being more social and
intuitive than traditional programming. But I think that's
an inevitable progression. As programs get more and more complex,
interacting with the computer will be more and more fuzzy and
intuitive, rather than mathematically precise. If you ask a
friend to go get you a cup of coffee, you don't feel you need
to spell out the details of how to do it. You trust that his
intuition about "get a cup of coffee" is close enough to yours
that whatever he does will be satisfactory. I think OO programming,
where you make calls on yet-to-be-implemented code, is like that.
(Maybe not *much* like that, but more like it than in languages
without inheritance.)
>But until a computer can figure out what an operation *means*
>absolutely =any= form of extensibility can lead to the abuse you
>describe.
I didn't say anything about abuse. I just said I hated it, and
I was lying when I said that. I always lie.
Ross Presser
>In article <ant180848313M+4%@gnelson.demon.co.uk>,
>Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>[...]
>>OO has instant appeal. Reading your first book about it is like
>>going to a revivalist meeting. Those who feel lost sink to their
>>knees and sob for the joy of being forgiven and welcomed, and
>>for all those lovely certainties.
>>
>>The week after that, you try to write your first slightly-involved
>>bit of OO code. You notice that, for instance, you are trying to
>>code a bird which is summoned by a whistle. So -- where does the
>>code for this go? Is it behaviour of the bird, or of the whistle,
>>or of the whistle-blower? Which object should be rewritten? Hmmm...
>>
>>And so the doubts begin to set in. Eventually, you're left with
>>just the vague, humanist ethics of the religion in question, and
>>none of the dogma.
>
>Nicely put.
Very nicely put.
>
>Given your example, I'd say that since the whistle and the bird are
>inherently linked, then the whistle would have to contain a pointer to the
>bird internally. When you blow the whistle (method on the whistle), it
>would send a message to the bird to tell it to go to the whistle (or the
>player).
>
Well, I don't think they're that closely tied together. I mean, think
about it in real life terms:
The whistle is an object which makes noise when air is blown through
it.
The whistleblower is an object who can blow air.
The bird is an object who can hear noise, and who can fly.
So, if you wanted to go crazy:
the whistleblower executes a blow-air method,
which sends an air message to the whistle,
which executes its receieve-air method,
which sends a noise message to the bird,
which executes its hear-noise method,
which triggers the fly-to-location method.
But if there was a tape recorder in the room too, then it could also
send a noise message to the bird. And if the whistleblower is
carrying several whistles, he only needs one blow-air method to send
air messages to any of them.
In general, if there's a real-life activity going on, you can
implement it by figuring out what the real objects are and what they
can do.
>In a bit more detail, I'd implement a method on the bird that made it fly
>to a certain location. The whistle would then call this method to make the
>bird go to the same location the whistle's in (or the whistle's holder).
>Special cases --- for example, if the player blows the whistle, the bird
>perches on its shoulder --- would be implemented in bird.goto(). This also
>gives you, for free, most of the functionality required for a twitch
>routine for the bird.
>
Mostly I agree.
>OO is a bit difficult to define. Basically, my perception of it is that it
>is a particular way to address a programming problem that may or may not
>be useful. I find it useful in cases where the problem reflects a
>real-world case; IF, UI widgetry, and so on. I find it monumentally
>useless where the problem *doesn't* reflect a real-world case. Take a look
>at the Java gibberish in process management and program start-up.
Hmmm. I can sort of agree -- I haven't seen the Java gibberish, but
I'm thinking of the gibberish in C++ streams. It's very easy to go
overboard with OO -- but different people have different ideas of what
overboard means in different cases.
[disclaimer: I have never finished an Inform game]
John Francis
David Given <dg@> wrote:
>In article <ant180848313M+4%@gnelson.demon.co.uk>,
>Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>[...]
>>bit of OO code. You notice that, for instance, you are trying to
>>code a bird which is summoned by a whistle. So -- where does the
>>code for this go? Is it behaviour of the bird, or of the whistle,
>>or of the whistle-blower? Which object should be rewritten? Hmmm...
>>
>>And so the doubts begin to set in. Eventually, you're left with
>>just the vague, humanist ethics of the religion in question, and
>>none of the dogma.
>
>Nicely put.
>
>inherently linked, then the whistle would have to contain a pointer to the
>bird internally. When you blow the whistle (method on the whistle), it
>would send a message to the bird to tell it to go to the whistle (or the
>player).
That's not how *I* would do it (which is another nice thing about OO;
eveybody thinks they know what it means, but no two people agree).
I'd make the whistle inherit from the abstract base class 'noisemaker',
which would send a sound to all objects that implemented a 'listen'
method. The bird would implement 'listen', and decide whether it
wanted to respond to the sound.
(The implementation of the 'sound' clas is left as an exercise for
the reader).
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.
Norman Ramsey
>> On the other hand, as you say, an OO program can make calls on
>> programs that are not yet written. One piece of code may call
>> an operation such as "display", "save", "restart", or whatever,
>> whose meaning has not yet been determined, since each new class
>> is free to reimplement these operations in arbitrary ways (only
>> restricted by the signature).
>
>The problem lies in "meaning has not yet been determined". Well-designed
>objects place specific restrictions on what can be done or not done and still
>be considered a correct use of the method.
Indeed. There's an *excellent* example of this in Chapter 6 of Greg
Nelson's book entitled `Systems Programming with Modula-3'---the
chapter explains the design of an I/O library. It's one of the most
compelling examples of OO that I've seen. An earlier version of the
chapter may be available as Report 53 from the Digital Systems
Research Center.
Norman
Kory Heath
> So, if you wanted to go crazy:
> the whistleblower executes a blow-air method,
> which sends an air message to the whistle,
> which executes its receieve-air method,
> which sends a noise message to the bird,
> which executes its hear-noise method,
> which triggers the fly-to-location method.
>
> But if there was a tape recorder in the room too, then it could also
> send a noise message to the bird.
If you *really* wanted to get crazy, you wouldn't send the noise message
directly to the bird; you'd do something more general, like sending a
message to the location's "noise air space" or something, so that other
objects in the area can also respond if they'd like. This speaks to the
intuition that the bird and the whistle shouldn't be so explicitly
connected - the bird doesn't know a thing about whistles, and the
whistle doesn't know a thing about birds, so maybe they shouldn't be
sending each other messages. The whistle just knows that it generates a
certain kind of sound, and the bird knows that it responds to a certain
kind of sound, so "sound" should be their point of contact.
Of course, to pull this off, you'd really need to create a full-blown
"Noise and Sound" class library, and you'd want to design it carefully,
to try to make it as general as possible. There are all sorts of nasty
questions here. How do you categorize sounds? Do you just define Sound
#43 == Whistle Blowing, or do you use objects and classes to represent
sounds and classes of sounds? How do you handle sound "scoping"? Does
sound travel between locations? Can it be blocked or muffled? Does the
"noise air space" broadcast messages to objects, or do objects have to
actively "listen" by sending messages to the "noise air space"?
Interestingly, that last issue turns out to be another version of
Graham's initial problem, moved up (or is it down?) a level, and it's
tempting to argue that this is exactly why "OO" is such a scam. :) My
sense is that these kind of problems will always exist on *some* level
(and probably not because of "OO", but because they just *exist*), but
pushing them out one level may be all the solution you need - the
problem may not be such a problem on the next level. In this specific
case, after the "noise" system is in place, most of your time is going
to be spent on the level of coding objects, and on that level the
problem *has* been solved - you no longer have to agonize about whether
the whistle should send a message to the bird, or vice-versa. I'm not
sure it matters so much whether the noise system "broadcasts" noise
messages, or whether objects need to actively "listen". The "noise"
system will just be designed one way or the other, and you'll code your
objects accordingly.
BTW, I understand that WorldClass does some interesting stuff with
sound, but I've never managed to find time to look at it. Anyone care
to fill me in?
--
Kory Heath
khe...@best.com
okbl...@usa.net
n...@labrador.cs.virginia.edu (Norman Ramsey) wrote:
>
> Indeed. There's an *excellent* example of this in Chapter 6 of Greg
> Nelson's book entitled `Systems Programming with Modula-3'---the
> chapter explains the design of an I/O library. It's one of the most
> compelling examples of OO that I've seen. An earlier version of the
> chapter may be available as Report 53 from the Digital Systems
> Research Center.
>
I'll see if I can dig that up. I like Wirth's languages on the whole and am
always dismayed to see the phrase "C-like syntax" pop-up. :-)
okbl...@usa.net
How much wronger could you be. %-)
> Oh, you're right! Actually, I was just kidding about hating OO,
> but I wasn't kidding about OO programming being more social and
> intuitive than traditional programming. But I think that's
I read recently that comp. sci. degrees are low interest for today's college
students, with them citing the isolated aspects of the job as a main reason
they're not interested. Maybe if they knew about the social aspects of OO.
"Hey, guys, get chicks with OO programming!" (I'm glad nobody thought of that
during the OO frenzy a few years back--you just *know* somebody would've put
that on their product.)
> an inevitable progression. As programs get more and more complex,
> interacting with the computer will be more and more fuzzy and
> intuitive, rather than mathematically precise. If you ask a
Yes and no. You'll have a lot of default behavior and it will certainly
*seem* fuzzier, I'm sure. But you'll still be able to ask the computer to
get you 8.5 oz. of coffee at exactly 105 degrees Farenheit.
> friend to go get you a cup of coffee, you don't feel you need
> to spell out the details of how to do it. You trust that his
> intuition about "get a cup of coffee" is close enough to yours
> that whatever he does will be satisfactory. I think OO programming,
Well that remains to be seen. I find that in the average conversation much
is assumed and much is assumed *wrongly*. Bringing it 'round to IF, even if
we "solved AI" there would be those whose inability to be clear would turn
into an (incorrect) evaluation of the system.
> where you make calls on yet-to-be-implemented code, is like that.
> (Maybe not *much* like that, but more like it than in languages
> without inheritance.)
>
LOL. OK.
> I didn't say anything about abuse. I just said I hated it, and
> I was lying when I said that. I always lie.
"Norman, coordinate!"
Daryl McCullough
>> ...As programs get more and more complex,
>> interacting with the computer will be more and more fuzzy and
>> intuitive, rather than mathematically precise. If you ask a
>
>Yes and no. You'll have a lot of default behavior and it will certainly
>*seem* fuzzier, I'm sure. But you'll still be able to ask the computer to
>get you 8.5 oz. of coffee at exactly 105 degrees Farenheit.
In principle, you will have that sort of control.
In practice, you won't. The problem is this: there
are only so many comprehensibly short programs. If
you design a language in which complex ideas can be
expressed succinctly, you will necessarily make it more
complex to express certain other things. The best you
can do is try to make a language in which the things
that you are most likely to want to say are simple,
and the things you are not likely to want to express
are harder. At some point, the complexity of asking
for something pointlessly precise will be more trouble
than it's worth.
You could, in principle, tell your friend how to
make coffee so that it will be exactly 8.5 oz at
105 degrees F. But, in practice, nobody would
ever go into that much detail (and if you did, your
friend would likely ignore most of it). At some
point, we give up precision in favor of simplicity.
>> friend to go get you a cup of coffee, you don't feel you need
>> to spell out the details of how to do it. You trust that his
>> intuition about "get a cup of coffee" is close enough to yours
>> that whatever he does will be satisfactory. I think OO programming,
>
>Well that remains to be seen. I find that in the average conversation much
>is assumed and much is assumed *wrongly*.
Sure. But imagine what life would be like if you *didn't* make
such assumptions! Buying a cup of coffee would take hours, if
not days, of explanation and negotiation.
>Bringing it 'round to IF, even if we "solved AI" there would
>be those whose inability to be clear would turn
>into an (incorrect) evaluation of the system.
The problem with having true AI is that computer programs
at that point would be just as ornery and exasperating as
people (if they're not already).
>> I didn't say anything about abuse. I just said I hated it, and
>> I was lying when I said that. I always lie.
>
>"Norman, coordinate!"
That does not compute.
Karma police, arrest this man.
He's talking in maths.
He's buzzing like a fridge.
He's like a detuned radio.
"Karma Police" from OK, Computer (Radiohead)
Jon Petersen
>
> I didn't say anything about abuse. I just said I hated it, and
> I was lying when I said that. I always lie.
Ah-ha. But if the liar said that, he'd be telling the truth, and if the
truth-teller said that, he'd be lying. Therefore you lie half the time
and tell the truth half the time; so the alligator pit is down the
right-hand path.
Jon
David Brain
gra...@gnelson.demon.co.uk (Graham Nelson) wrote:
> And so the doubts begin to set in. Eventually, you're left with
> just the vague, humanist ethics of the religion in question, and
> none of the dogma.
I can't tell if you're implying that this is a good or a bad thing?
--
David Brain
London, UK
> Light creates shadow; light destroys shadow. <
> Such is the transience of darkness. <
Doeadeer3
(John Francis) writes:
>I'd make the whistle inherit from the abstract base class 'noisemaker',
>which would send a sound to all objects that implemented a 'listen'
>method. The bird would implement 'listen', and decide whether it
>wanted to respond to the sound.
Right on.
Just because it's OO doesn't mean it has to be convoluted. "If a tree falls in
the woods and no one is around to hear it, does it still make a sound?"
Maybe it does mean you have to think harder about what are REALLY the basic
elements ("chunks", whatever).
I love classes and inheritance. Like Jarb said it saves pages and pages of
code. And like Magnus said, I like to sweep my dirt (routines) into objects. I
like tidiness.
Doe :-) (Sold on OO and won't apologize for it, so there.)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
David Given
[...]
>Of course, to pull this off, you'd really need to create a full-blown
>"Noise and Sound" class library, and you'd want to design it carefully,
>to try to make it as general as possible. There are all sorts of nasty
>questions here. How do you categorize sounds? Do you just define Sound
>#43 == Whistle Blowing, or do you use objects and classes to represent
>sounds and classes of sounds? How do you handle sound "scoping"? Does
>sound travel between locations? Can it be blocked or muffled? Does the
>"noise air space" broadcast messages to objects, or do objects have to
>actively "listen" by sending messages to the "noise air space"?
Hmm.
Have a Room class. One of the things this does is handle sounds.
when I blow the whistle, the whistle sends a message to the room telling
it that it's made a sound of type SND_WHISTLE of volume 5, originating
from the whistle. The room then sends messages back to all its children
(which will hear the sound) so that they can process it. (For example, if
the bird's in the room it'll hear it and go to the whistle.)
It *also* sends the sound on to any rooms adjoining, decrementing the
volume by one (when the volume reaches zero, the sound vanishes). Each
adjoining room then does the same (excepting the room from which the sound
originally came). So, when you blow the whistle, all objects in the
vicinity will hear it, depending on how far away it is.
In one room, though, there is a wall (or something like). When this hears
a sound, it just broadcasts it again at the same volume. So, I blow my
whistle; the sound is distributed throughout the map; when the sound
reaches the wall, it echoes, and the echo distributed back again.
> BLOW WHISTLE
Wheep!
You hear a sharp whistle to the north.
I assume that sound travels at a reasonable velocity in this game...
--
+- David Given ----------------+
| Work: d...@tao.co.uk | Eat the rich. The poor are tough and
| Play: dgi...@iname.com | stringy.
+- http://wiredsoc.ml.org/~dg -+
Graham Nelson
<URL:mailto:da...@atlan.cix.co.uk> wrote:
> In article <ant180848313M+4%@gnelson.demon.co.uk>,
> gra...@gnelson.demon.co.uk (Graham Nelson) wrote:
>
> > And so the doubts begin to set in. Eventually, you're left with
> > just the vague, humanist ethics of the religion in question, and
> > none of the dogma.
>
> I can't tell if you're implying that this is a good or a bad thing?
That's humanism for you, I'm afraid.
okbl...@usa.net
da...@cogentex.com (Daryl McCullough) wrote:
>
> In principle, you will have that sort of control.
> In practice, you won't.
I dunno. The decisions have to be made at some point. If, for you, the
perfect cup of copy is exactly 8.5 oz. at 105 degrees, well, you're not going
to be happy with not having that kind of control. And since the
coffee-making-robot (doubtless named Marvin) is going to have to have some
point at which it makes that decision, I would imagine that *that* particular
decision is one you'll get to be in on.
Other decisions, yes, you're right, they will doubtless be hidden. Like you
probably won't be able to tell Marvin (actually Joe Di would be a better name
for a coffee-making-robot) to use eight byte integers when calculating the
coffee temperature.
> Sure. But imagine what life would be like if you *didn't* make
> such assumptions! Buying a cup of coffee would take hours, if
> not days, of explanation and negotiation.
That's why I gave up drinking coffeee. ;-)
> The problem with having true AI is that computer programs
> at that point would be just as ornery and exasperating as
> people (if they're not already).
That's not *necessarily* true, but somebody at some point will decide that
artificial personalities are "cute", and like Windows '95, we'll be stuck with
them.
But why should I believe you? You always lie! You said so!
Jonadab the Unsightly One
>
> I'll see if I can dig that up. I like Wirth's languages on the whole and
am
> always dismayed to see the phrase "C-like syntax" pop-up. :-)
>
> [ok]
I used to dread C-like syntax. All punctuation. Impossible to
comprehend.
I do not think of it as C-like syntax anymore.
Now I think of it as Inform-like syntax, and it is a
Good Thing. It means I can relate to it directly
without performing mental translations like "Okay, this
means that..."
--
At Your Service,
Jonadab the Unsightly One.
remove spaces: j o n a d a b @ b r i g h t . n e t
Jonadab the Unsightly One
> > an inevitable progression. As programs get more and more complex,
> > interacting with the computer will be more and more fuzzy and
> > intuitive, rather than mathematically precise. If you ask a
>
> Yes and no. You'll have a lot of default behavior and it will certainly
> *seem* fuzzier, I'm sure. But you'll still be able to ask the computer
to
> get you 8.5 oz. of coffee at exactly 105 degrees Farenheit.
But if you are using Windows '9x you will have to write your own
device driver to do it. Otherwise you will be stuck with choosing
between frozen, lukewarm, and scalding.
> > friend to go get you a cup of coffee, you don't feel you need
> > to spell out the details of how to do it. You trust that his
> > intuition about "get a cup of coffee" is close enough to yours
> > that whatever he does will be satisfactory. I think OO programming,
Depend how well your friend knows you.
Depend, by analogy, how much customisation you have done to your
software.
L. Ross Raszewski
okbl...@usa.net wrote:
> In article <6rflea$l...@drn.newsguy.com>,
> da...@cogentex.com (Daryl McCullough) wrote:
> >
> > In principle, you will have that sort of control.
> > In practice, you won't.
>
> I dunno. The decisions have to be made at some point. If, for you, the
> perfect cup of copy is exactly 8.5 oz. at 105 degrees, well, you're not going
> to be happy with not having that kind of control. And since the
> coffee-making-robot (doubtless named Marvin) is going to have to have some
> point at which it makes that decision, I would imagine that *that* particular
> decision is one you'll get to be in on.
Doubt it. More likely, Marvin's programmer has decided that the "perfect" cup
of coffee is 8 oz at 100 degrees, and if you tell marvin you want something
different, he'll hapily say "I only understood you as far as wanting to take
the northeast wall".
THis is actually one of the problems I have with OO in practice. OO
de-emphasizes special cases. If you happen to be a special case, you're
screwed. I use OO in theory plenty. I use OO concepts in C and Inform
programming. the problem is that when you have a rigidly implemented OO
system, thinking outside the box (or the object) is illegal. When I go to
implement a special case of interaction, I end up being limited becuse the
person who wrote this hypothetical library which I can use withoiut knowing
its inner workings never anticipated anyone needing to do what it is that I
need to do.
(Strangely enough, I've been decreasing the code size of my own inform WIP by
_removing_ OO constructions)
TenthStone
>I assume that sound travels at a reasonable velocity in this game...
Well, assuming an average distance of fifty feet or so from Room A
to Room B, and an average turn of thirty seconds, and that the temperature
is 32 degrees fahrenheit (0 celsius) and the game takes place at sea level,
meaning that the speed of sound is approximately 1088 feet per second,
then the fuse should go off in (50(n of passage rooms + 1)/32640) turns
(rounded down).
-----------
The inperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us
Doeadeer3
Olsson) writes:
>As I've
>stated a couple of times, IMO the greatest weakness of the Inform
>library is its almost total lack of OO (or, if you're not sold on OO
>yet, its lack of modularity and modifiability).
Someone wrote me, suggesting *l* rewrite the Inform library in an OO manner.
For one thing, I wouldn't presume. The author of Inform, Mr. Nelson, should be
the one to maintain it, update it and make any changes.
Secondly, I doubt I have that level of skill.
Thirdly, would the rewritting the Inform library to be more OO, be an
improvement? I think, yes, some aspects would be improved, maybe some GREATLY
improved (right now there are a lot of inconsistencies. For instance, the way
some routines return and some don't under certain circumstances,. i.e. no
uniform manner in the way in which routines return false... or, for that,
matter, true. Sorry, I know what I mean but can't express it more clearly.)
The big BUT is, greatly increasing the learning overhead. (Also, I assume Mr.
Nelson has been trying to maintain backward compatibility, but setting that
issue aside for now...) Currenty, one doesn't really NEED to understand OO to
start ing learning Inform. So if one is an OO "virgin", one is eased into the
whole concept of OO gradually. All the new learner needs to understand is the
basic concept of "objects". Room object rooms, takeable objects, animate
objects. No biggee, not that hard to "get".
But imagine a REAL OO Inform library. (This is psuedo code.)
Player
take
[; send.obj.be_taken;
Object
be_taken
[; if (self has static or scenery) repond no_can_do_message;
The newbie with no OO background at all, would be totally overwhelmed.
This "ease them into OO method and once they get it they will like" or "they
don't REALLY need to understand OO to program in Inform", is IMHO, much better.
(On the former, one word... Jarb. On the later, one could write a game with no
classes at all.)
Doe :-)
TenthStone
>In article <6rflea$l...@drn.newsguy.com>,
> da...@cogentex.com (Daryl McCullough) wrote:
>>
>> In principle, you will have that sort of control.
>> In practice, you won't.
>
>I dunno. The decisions have to be made at some point. If, for you, the
>perfect cup of copy is exactly 8.5 oz. at 105 degrees, well, you're not going
>to be happy with not having that kind of control. And since the
>coffee-making-robot (doubtless named Marvin) is going to have to have some
>point at which it makes that decision, I would imagine that *that* particular
>decision is one you'll get to be in on.
Well, the 8.5 ounces will probably be approximated by the robot in return for
greater speed. It might be 8.501 ounces. Or maybe it'll be designed in France,
and all the Americans will have to figure out how to convert 8.5 ounces into
litres.
>Other decisions, yes, you're right, they will doubtless be hidden. Like you
>probably won't be able to tell Marvin (actually Joe Di would be a better name
>for a coffee-making-robot)
I suspect people would call them stupid names, just like they call their children
stupid names.
>to use eight byte integers when calculating the coffee temperature.
Eight byte integers? My god, man, how hot do you need your bloody coffee?
2^64... well, that's ((2^10)^6)(2^4), which is about +-8 quintillion degrees.
"Hey Pot-Pot, could you run this down to the particle accelerator?"
>> Sure. But imagine what life would be like if you *didn't* make
>> such assumptions! Buying a cup of coffee would take hours, if
>> not days, of explanation and negotiation.
>
>That's why I gave up drinking coffeee. ;-)
Well, here at the ward they used to enforce a mandatory two-hour
waiting period on purchasing a cup of coffee, so that we'd think twice
before trying to scald ourselves to death with our coffee-which-is-hotter-
than-the-speed-of-light-is-fast.
>> The problem with having true AI is that computer programs
>> at that point would be just as ornery and exasperating as
>> people (if they're not already).
>
>That's not *necessarily* true, but somebody at some point will decide that
>artificial personalities are "cute", and like Windows '95, we'll be stuck with
>them.
Minimum Bob, I always say.
>But why should I believe you? You always lie! You said so!
Have you read any of Asimov's Robot series? His idea is that humans will
grow so petrified of being replaced by robots that we will create only limited,
emotionless robots that still manage somehow to evolve and become incredibly
man-like while mastering the art of telepathy. Granted, not all of that is pertinent
to the issue at hand.
Adam J. Thornton
TenthStone <mcc...@erols.com> wrote:
>Well, the 8.5 ounces will probably be approximated by the robot in return for
>greater speed. It might be 8.501 ounces. Or maybe it'll be designed in France,
>and all the Americans will have to figure out how to convert 8.5 ounces into
>litres.
"Eh? You want *coffee*, Yankee-cultural-imperialist swahn? I *speet* in
your grounds! Ah wave ma private parts at your maiden aunties, you
small-minded Levi-exporting wahper of other people's bottoms! En Paree, we
*keel* tourists who ohrdehr *coffee*! After humeeeeeeliating them! An'
then we *serve* them up to *other* tourists in a stew with Wild 'Orses from
WashingTON and wino pee, and tell them eet is Boeuf De Fromagetete!
Coffee! HA!"
I think I'll stick with the old-fashioned method of caffeine abuse, myself.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
okbl...@usa.net
"Jonadab the Unsightly One" <jon...@zerospam.com> wrote:
>
> I do not think of it as C-like syntax anymore.
>
> Now I think of it as Inform-like syntax, and it is a
> Good Thing. It means I can relate to it directly
> without performing mental translations like "Okay, this
> means that..."
>
Amazing what a little shift in perspective will do. I can relate to C syntax
just fine, though: I just don't like it much.
[ok]
okbl...@usa.net
L. Ross Raszewski <rras...@hotmail.com> wrote:
>
> Doubt it. More likely, Marvin's programmer has decided that the "perfect" cup
> of coffee is 8 oz at 100 degrees, and if you tell marvin you want something
> different, he'll hapily say "I only understood you as far as wanting to take
> the northeast wall".
>
Then, presumably, Marvin's competitor, Joe Di, has captured the market by
allowing not only variations in volume and temperature, but the correct
amount, rotation and angle for whipping lattes. :-)
> THis is actually one of the problems I have with OO in practice. OO
> de-emphasizes special cases. If you happen to be a special case, you're
> screwed. I use OO in theory plenty. I use OO concepts in C and Inform
> programming. the problem is that when you have a rigidly implemented OO
> system, thinking outside the box (or the object) is illegal. When I go to
> implement a special case of interaction, I end up being limited becuse the
> person who wrote this hypothetical library which I can use withoiut knowing
> its inner workings never anticipated anyone needing to do what it is that I
> need to do.
It isn't OO that de-emphasizes special cases, it's designers with a lack of
imagination. I've run into that same thing, and all it has ever meant to me,
in practice, is that I had to go further back down the hierarchy to get what
I want--except in one case where I had to re-create (clone) an object's
interface. But that was a language limitation.
> (Strangely enough, I've been decreasing the code size of my own inform WIP by
> _removing_ OO constructions)
There's nothing strange about that. If you write general OO, you're going to
have to code for cases (or the *possibiity* of cases) that aren't going to
come up in your case. Structured code can probably always be shorter.
Unstructured code can be shorter still. And faster. (Assembler being the
prime example of this.) It's just *lots* harder to work with.
okbl...@usa.net
mcc...@erols.com (TenthStone) wrote:
>
> Well, the 8.5 ounces will probably be approximated by the robot in return for
> greater speed. It might be 8.501 ounces. Or maybe it'll be designed in
France,
> and all the Americans will have to figure out how to convert 8.5 ounces into
> litres.
>
Somehow I think a robot smart enough to pour a cup of coffee is going to be
smart enough to convert to and from metric. I suppose it would be ironic if
they developed a robot that could function physically very similarly to a
human but the processing demand was so great that it couldn't do any of the
things we've come to expect from computers (like calculations, etc.) and the
robots were just as frustrated with computers as we are. :-)
> I suspect people would call them stupid names, just like they call their
children
> stupid names.
I think people are more careful with their robots in general. ;-)
>
> >to use eight byte integers when calculating the coffee temperature.
>
> Eight byte integers? My god, man, how hot do you need your bloody coffee?
> 2^64... well, that's ((2^10)^6)(2^4), which is about +-8 quintillion degrees.
> "Hey Pot-Pot, could you run this down to the particle accelerator?"
>
I suppose I should dissemble here and say that my point wasn't why you would
*want* to do that but rather that you wouldn't have that level of control.
But of course, in a rare bout of honesty, I must confess that I meant 8-*bit*
integers.
>
> Well, here at the ward they used to enforce a mandatory two-hour
> waiting period on purchasing a cup of coffee, so that we'd think twice
> before trying to scald ourselves to death with our coffee-which-is-hotter-
> than-the-speed-of-light-is-fast.
>
Using the standard conversion of heat->speed, I presume.
>
> Minimum Bob, I always say.
>
In a bizarre twist, Microsoft develops an add-on for Windows called "Bob"
which is instead based on Billy Bob Thornton's character in "Sling Blade"....
> Have you read any of Asimov's Robot series? His idea is that humans will
> grow so petrified of being replaced by robots that we will create only
limited,
> emotionless robots that still manage somehow to evolve and become incredibly
> man-like while mastering the art of telepathy. Granted, not all of that is
pertinent
> to the issue at hand.
No, and Asimov used to drive me nuts with that stuff. Suffice to say that I
disagree with his interpretation of intelligence and *truly* disliked the
ending of "Star Trek: The Motion Picture".
graham...@hotmail.com
> In article <6rbae4$mi9$1...@bartlet.df.lth.se>, m...@bartlet.df.lth.se (Magnus
> Olsson) writes:
>
> >As I've
> >stated a couple of times, IMO the greatest weakness of the Inform
> >library is its almost total lack of OO (or, if you're not sold on OO
> >yet, its lack of modularity and modifiability).
Yay! I think OO is great, particularly in IF. It's no coincidence that
"woohoo" contains "oo" twice.
Anyway, a good ooification of the Inform library should be done in such a way
that it is transparent to the user, so we don't have to worry about scaring
non- ooey people. Some of the ooey power will be lost, but no more than is
already lost.
Or, you could make a whole new engine from scratch, like ClassAct, which Erik
Hetzner is doing. Then, you can use all the ooey power you want.
- GLYPH
Joe Mason
<graham...@hotmail.com> wrote:
>
>Yay! I think OO is great, particularly in IF. It's no coincidence that
>"woohoo" contains "oo" twice.
Hah! Mind if I steal that for my .sig? (I don't have one cause I could
never find a good quote.)
>Or, you could make a whole new engine from scratch, like ClassAct, which Erik
>Hetzner is doing. Then, you can use all the ooey power you want.
WorldClass, ClassAct - I like the names. Wish I had time to help with this.
Joe
Adam Atkinson
>OO has instant appeal.
This hasn't been my experience.
>Reading your first book about it is like
>going to a revivalist meeting.
What, you suddenly realise you're in a room full of lunatics?
>Those who feel lost sink to their
>knees and sob for the joy of being forgiven and welcomed, and
>for all those lovely certainties.
Hmm.. I've tried writing some programs in Java, but when I found out
that inputting floating-point numbers from the command line required
arcane knowledge, I decided to just give up.
--
Adam Atkinson (gh...@mistral.co.uk)
You got a light, mac?
No, but I've got a dark brown overcoat.
Den of Iniquity
>"Eh? You want *coffee*, Yankee-cultural-imperialist swahn?"
Hmm, coffee might have achieved a special cultural status in the US but if
you really want to see coffee drunk properly, watch the Turks. I believe
Turkey has the highest incidence of throat cancers in the world and it's
mostly attributal to astonishingly proficient caffeine abuse.
--
Den
Adam J. Thornton
I would have thought it was mostly attributable to incredibly ubiquitous
smoking of unbearably AWFUL cigarettes ALL THE TIME except when the Turks
are taking GIGANTIC hits off of huge water pipes stuffed to the gills with
even NASTIER tobacco.
Jonadab the Unsightly One
<Pine.SGI.3.95L.98082...@ebor.york.ac.uk>...
> On 22 Aug 1998, Adam J. Thornton wrote:
> >"Eh? You want *coffee*, Yankee-cultural-imperialist swahn?"
>
> Hmm, coffee might have achieved a special cultural status in the US but
if
> you really want to see coffee drunk properly, watch the Turks. I believe
> Turkey has the highest incidence of throat cancers in the world and it's
> mostly attributal to astonishingly proficient caffeine abuse.
I have heard tales of incredible coffee in places like Papau New Guinea,
but I
a) do not drink coffee
2. have never been outside of North America
D: therefore cannot verify this assertion.
--
Dyslexic email address: ten.thgirb@badanoj
Den of Iniquity
>Den of Iniquity <dms...@york.ac.uk> wrote:
>>I believe Turkey has the highest incidence of throat cancers in the
>>world and it's mostly attributal to astonishingly proficient caffeine
>>abuse.
>I would have thought it was mostly attributable to incredibly ubiquitous
>smoking of unbearably AWFUL cigarettes ALL THE TIME except when the Turks
>are taking GIGANTIC hits off of huge water pipes stuffed to the gills with
>even NASTIER tobacco.
Wow. Capital abuse. Scary. Anyway.... From what I've heard, the average
hookah is quite mild (no puns desired, folks). Perhaps all that filtering
equipment is to make up for the quality of the tobacco. I dunno, I'm no
smoker. And there's a difference between the oesophagus and the trachea,
though my mouth has a tendency to get it wrong from time to time. (Choke,
splutter.)
--
Den
David Rush
> > But you'll still be able to ask the computer to
> > get you 8.5 oz. of coffee at exactly 105 degrees Farenheit.
> But if you are using Windows '9x you will have to write your own
> device driver to do it. Otherwise you will be stuck with choosing
> between frozen, lukewarm, and scalding.
> > > friend to go get you a cup of coffee, you don't feel you need
> > > to spell out the details of how to do it.
> Depend how well your friend knows you.
> Depend, by analogy, how much customisation you have done to your
> software.
Therefore: Linux is your friend.
QED.
david rush
--
Brought to you by the worldwide Linux conspiracy...
Julian Fleetwood
>On 22 Aug 1998, Adam J. Thornton wrote:
>>"Eh? You want *coffee*, Yankee-cultural-imperialist swahn?"
>
>Hmm, coffee might have achieved a special cultural status in the US but if
>Turkey has the highest incidence of throat cancers in the world and it's
>mostly attributal to astonishingly proficient caffeine abuse.
:( All this talk of coffee and I told my self I wouldn't drink any for a
month.
Oh, well. Only two more weeks.
--
Julian Fleetwood (http://surf.to/free4all) | G!>GCS d-- s+:- a16 C+(++) p? L
E-W++ N++
IF: http://www.tip.net.au/~mfleetwo/if/index.htm | o K- w++ O M+ !V PS PE Y+
G e h! PGP-
CBG: http://www.tip.net.au/~mfleetwo/cbg/index.htm | t+ X+++ R(+) tv b+(++)
DI+ D++ r y?