[Inform] Why Global Variables?
Kevin Forchione
easy to have confined the variable to the object it relates to (parser
variables to the parser, library variables to the library). I have hacked
the library as an experiment and have found that the program functions fine
without them (i.e. having transfered them to their corresponding object and
referencing them from the object)
I can only speculate that the reason for their use must be either one of
space or speed (or both), but as I have no statistics on this I am at a
loss.
Does anyone know why Inform has such a mixture of Object orientation and
global variable?
Kevin
edr...@concentric.net
Kevin Forchione wrote in message ...
>I'm puzzled at the use of global variables by Inform, as it seems just as
>easy to have confined the variable to the object it relates to (parser
>variables to the parser, library variables to the library). I have hacked
>the library as an experiment and have found that the program functions fine
>without them (i.e. having transfered them to their corresponding object and
>referencing them from the object)
In Anchorhead, I found it convenient to set a global variable "Chapter" and
set it to 1, 2, 3 or 4 as needed -- as opposed to, say, having a "Chapter"
object and setting its number property to 1, 2, 3 or 4. Just easier to
remember and easier to type.
--M
================================================
"If you don't eat your meat, you can't have any pudding.
How can you have any pudding if you don't eat your meat?"
Evin C Robertson
Global Var.. by Andrew Plo...@netcom.co
> To some extent it's both code size and speed. Reading a value from a
> global (or local) variable can be done within an opcode -- there's an
> addressing mode for that. Reading from a common property takes an extra
> full opcode, and reading from an individual property is implemented with a
> function call which (I believe) searches down a linked list with a z-code
> loop. So moving frequently-used variables like "noun" and "second" to
> individual properties could slow things down quite a bit.
Just to expand a little bit:
For common properties, you just call get_prop (for 1 or 2 byte
properties) or get_prop_addr (for longer properties).
Common property #3 points to the individual properties. Each individual
property table is a simple list which eats lots of space (2+3*n overhead
where n=number of properties), and has to be looped through by the
z-code, as it's not directly supported by the interpreter.
Common properties are stored in decreasing order, so to access an
individual property, the interpreter first loops over whichever
properties numbered higher than 3 an object has, gives the value to the
program, which then loops through (in z-code) the individual properties.
So yes, global variables are significantly faster than individual
properties. Global variables are like registers to the zmachine. Some
interpreters' stacks will be slightly faster, but due to the limited
number of parameters per function, passing things like 'self' and 'noun'
to functions would be painful.
Of course, unless you're playing on a palm pilot or run a dozen
objectloops every turn, you're not likely to notice any of this.
Andrew Plotkin
> I'm puzzled at the use of global variables by Inform, as it seems just as
> easy to have confined the variable to the object it relates to (parser
> variables to the parser, library variables to the library). I have hacked
> the library as an experiment and have found that the program functions fine
> without them (i.e. having transfered them to their corresponding object and
> referencing them from the object)
To some extent it's both code size and speed. Reading a value from a
global (or local) variable can be done within an opcode -- there's an
addressing mode for that. Reading from a common property takes an extra
full opcode, and reading from an individual property is implemented with a
function call which (I believe) searches down a linked list with a z-code
loop. So moving frequently-used variables like "noun" and "second" to
individual properties could slow things down quite a bit.
Mostly, though, it's just historical. Individual properties are a recent
Inform innovation. Before that, there were only common properties, with a
hard limit of 47 in the game -- versus 240 global variables. Authors were
(and still are) much more likely use to properties anyway, so it was a
sensible decision. Now it'd be a lot of work to change, for little gain.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Jonadab the Unsightly One
> Mostly, though, it's just historical. Individual properties are a recent
> Inform innovation. Before that, there were only common properties, with a
> hard limit of 47 in the game -- versus 240 global variables.
Furthermore, a lot of those global variables, as the source code of
the library at least used to indicate in the comments, are really
local variables for the parser, because there's a hard limit on the
number of local variables any given routine can have, and the
parser is complex enough to run out.
> Authors were
> (and still are) much more likely use to properties anyway,
Indeed. For all practical purposes, properties are
global variables. They're just logically attached to
a particular object and affect that object, but you
can check or change them anywhere, which comes
in very handy.
I really only use globals for arrays and a couple of
matters of state that don't have to do with any
particular object (like whether proportional fonts are
on or off -- and even those could be put in a
general_values object if I cared to bother).
What I don't get is the big deal about individual
properties. With sensible aliasing, I can't see
running out of general properties.
There are almost no properties that can't be
aliased to at least one other property with no trouble.
(Just a few library ones like description and before).
In my big game I've got more than one property with
at least three aliases, and no troubles, because
different classes use them different ways and no
objects inherit from more than one of those classes.
I don't alias attributes, though.
That way lies madness.
I've even hacked my library to kill the alias
between female and absent.
> so it was a
> sensible decision. Now it'd be a lot of work to change, for little gain.
Little and dubious.
- jonadab
Doeadeer3
In article <eVAUhDCD#GA.204@upnetnews05>, "Kevin Forchione"
<Lys...@email.msn.com> writes:
>I can only speculate that the reason for their use must be either one of
>space or speed (or both), but as I have no statistics on this I am at a
>loss.
There is another reason (which took me awhile to figure out), at least when it
comes to global properties.
Global properties are assigned to all objects, i.e., making size a global
property (Property size = 0;) for instance, gives all objects a size. So
something like:
if (obj.size > 4)
will never encounter an error, because objects without a definited size will be
presumed to have the default value of 0 (since size is global).
But local properities can give errors. If you test an object which does not
have the local property size assigned to it, an error results. You must first
check if the object HAS the local property, if (obj provides size) before you
can check it's value.
This may seem a minor matter, but sometimes it makes nice to have some
properties be global.
I have found other reasons for global VARIABLES, sometimes I need something
that is independent of any routine.
Global intoxicated = 0; Maybe the player can get drunk in several ways and the
code reporting what can happen is in several places.
Go : if (intoxicated > 3) "You slip and slide and fall flat on your face.";
Doe :-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Kevin Forchione
Graham's words from the DM:
The objects in a program are its constituent parts: little lumps of code and
data. The starting point of an "object-oriented language'' is that it's good
design to tie up pieces of information in bundles with the pieces of program
which deal with them. But the idea goes further:
1. An object is something you can communicate with. (It's like a company
where many people work in the same building, sharing the same address: to
the outside world it behaves like a single person.)
2. Information inside the object can be kept concealed from the outside
world (like a company's confidential files). This is sometimes called
"encapsulation''.
3. The outside world can only ask the object to do something, and has no
business knowing how it will be done. (The company might decide to change
its stock-control system one day, but the outside world should never even
notice that this has happened, even though internally it's a dramatic
shift.)
All three principles have been seen already for routines: (1) you can call a
routine, but you can't call "only this part of a routine''; (2) the local
variables of a routine are its own private property, and the rest of the
program can't find out or alter their values; (3) as long as the routine
still accomplishes the same task, it can be rewritten entirely and the rest
of the program will carry on working as if no change had been made.
Why bother with all this? There are two answers. First and foremost, Inform
was designed to make adventure games, where objects are the right idea for
representing items and places in the game. Secondly, the 'object' approach
makes sense as a way of organising any large, complicated program.
The other key idea is communication. One can visualise the program as being
a large group of companies, constantly writing letters to each other to
request information or ask for things to be done. In a typical "message'',
one object A sends a detailed question or instruction to another object B,
which replies with a simple answer. (Again, we've seen this already for
routines: one routine calls another, and the other sends back a return
value.) "
I agree with this, and I think it's time for Inform to begin to "take the
step up into a larger world." Considerations of portability are important,
as are considerations of elegance and beauty, but I do not agree that Inform
should continue to pay homage to the technology of the 1980s.
More could be done with the library, to enhance and clean it up. Certain
things should perhaps ... just perhaps become standard, like a working
GAMETIME system capable of handling more complex wait commands and show the
passage of time as well as turns. (I know there are library extensions for
this, but it should probably be part of the main library.)
Perhaps it is time for backward compatibility to draw a line in the sand, so
that the system can be allowed to expand and incorporate new features
without the crippling effects of having to accomodate older versions.
How many innovations and extensions have become commonplace in our games?
(Who among us is without MOVECLAS.H or FOLLOWER.H? or INFO.H?) And why, for
heaven's sake, do you have to have extended grammar just to say "Hit Troll
with club".
It's true, it's fun to develop innovations, almost as fun as playing
text-based games themselves. But we shouldn't have to go re-inventing the
wheel and hacking the library everytime we want to say "wait 1 hour and 30
minutes."
I agree with Doeadeer3 about the use of global variables, and there are
conveniences in using them. I agree with the others about concern over speed
and size (although with my pc I don't notice either). But these are pretty
impressive words from Mr. Nelson, and an awesome vision that has yet to be
achieved.
Kevin
======================================================
Doeadeer3 wrote in message <19981109224610...@ngol01.aol.com>...
Kevin Forchione
Kevin
======================================================
Andrew Plotkin
> I agree with this, and I think it's time for Inform to begin to "take the
> step up into a larger world." Considerations of portability are important,
> as are considerations of elegance and beauty, but I do not agree that Inform
> should continue to pay homage to the technology of the 1980s.
Never confuse homage and laziness. :)
> More could be done with the library, to enhance and clean it up.
Absolutely. I'm too lazy to do this, of course... (double :)
Although I think Graham's standard library is a good thing to have around.
A new alternative, from a fresh point of view, is what I'd like to see.
> Certain
> things should perhaps ... just perhaps become standard, like a working
> GAMETIME system capable of handling more complex wait commands and show the
> passage of time as well as turns. (I know there are library extensions for
> this, but it should probably be part of the main library.)
Ah. No. It should be *easy to add* to the library, but I do *not* think a
standard library should incorporate every feature. Features are
*incredibly* game-specific; the implementation details vary. (Look at
fluids, ropes, connectable object...) It's no good including lots of code
in every game which will have to be overridden *even in the few games that
use it.*
> How many innovations and extensions have become commonplace in our games?
> (Who among us is without MOVECLAS.H or FOLLOWER.H? or INFO.H?)
I don't use any of those. I use hacks that conflict with them, in fact,
which is one reason standard libraries shouldn't get overspecialized.
> And why, for
> heaven's sake, do you have to have extended grammar just to say "Hit Troll
> with club".
Same thing, from the player's point of view. *A game should not have every
possible verb*. It's bad design. I routinely take verbs out of the
standard grammar, and I should probably do it even more.
The grammar system is one of the things about Inform that I wholeheartedly
approve of. It's trivial to extend; you can add "hit troll with club" or
"turn bolt with wrench", whichever is appropriate to your game. It doesn't
doesn't *have* to do everything.
The bits I think need improvement are the bits between parsing and action:
disambiguation, implied objects, automatic taking. These are things that
the library *doesn't* let you easily extend or modify. The library is
written to handle this all for you, and the result is inadequate and
frustrating.
Kevin Forchione
I agree on your modular approach perspective, and you're quite right about
not having everything handled in the library. I think a sort of
'plug-n-play' approach would be best.
Andrew Plotkin wrote in message ...
>Kevin Forchione (Lys...@email.msn.com) wrote:
>> I agree with this, and I think it's time for Inform to begin to "take the
>> step up into a larger world." Considerations of portability are
important,
>> as are considerations of elegance and beauty, but I do not agree that
Inform
>> should continue to pay homage to the technology of the 1980s.
>
>
>
>
>Although I think Graham's standard library is a good thing to have around.
>A new alternative, from a fresh point of view, is what I'd like to see.
>
>> things should perhaps ... just perhaps become standard, like a working
>> GAMETIME system capable of handling more complex wait commands and show
the
>> passage of time as well as turns. (I know there are library extensions
for
>> this, but it should probably be part of the main library.)
>
>standard library should incorporate every feature. Features are
>*incredibly* game-specific; the implementation details vary. (Look at
>fluids, ropes, connectable object...) It's no good including lots of code
>in every game which will have to be overridden *even in the few games that
>use it.*
>
>> (Who among us is without MOVECLAS.H or FOLLOWER.H? or INFO.H?)
>
>which is one reason standard libraries shouldn't get overspecialized.
>
>> heaven's sake, do you have to have extended grammar just to say "Hit
Troll
>> with club".
>
Doeadeer3
In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) writes:
>Ah. No. It should be *easy to add* to the library, but I do *not* think a
>standard library should incorporate every feature. Features are
>*incredibly* game-specific; the implementation details vary. (Look at
>fluids, ropes, connectable object...) It's no good including lots of code
>in every game which will have to be overridden *even in the few games that
>use it.*
I agree with this. Look at irene (sorry, irene), she kept running out of memory
space because she tried to make a template she could use for every future game
(which she would add game-specific objects, npcs, etc. to later). Problem -- It
got too big. (Of course, she put two of everthing in, but the problems are
obvious.)
>The grammar system is one of the things about Inform that I wholeheartedly
>approve of. It's trivial to extend; you can add "hit troll with club" or
>"turn bolt with wrench", whichever is appropriate to your game. It doesn't
>doesn't *have* to do everything.
All we really need is more sample code at gmd.de, maybe extremely simple, that
will show newbies (and more experienced programmers) the way to do these
things.
>The bits I think need improvement are the bits between parsing and action:
>disambiguation, implied objects, automatic taking. These are things that
>the library *doesn't* let you easily extend or modify. The library is
>written to handle this all for you, and the result is inadequate and
>frustrating.
Well it would probably help if the library was written to be more OO. I keep
finding inconsistencies between verbsub routines (not behaving similarily) and
other things that annoy me. Of the total Inform system, the library is the
weakest part, probably because it has been through so many revisions.
We could use things like Lucian's take all, better disambiguation, better
conversation control (if I knew what I was doing I would like to rewrite that
part of the parser that deals with turning a non-understood NPC order into "say
such and such" to the NPC -- include questions and, if possible, include
someway for the NPC not to have to be addressed with name, each time.) So
agreed again.
So, Zarf, when are you going to rewrite the library?
Doe :-) Hehehe. (I know you said, no.)
Andrew Plotkin
> Of the total Inform system, the library is the
> weakest part, probably because it has been through so many revisions.
And -- I'm not sure whether this is incredible good luck, good planning,
or inevitable, but I'm thankful anyway -- the library is the one part of
the Inform system that you can completely rewrite without sacrificing
portability for the player, portability for the author, *or* being Graham.
Go for it! (He said, quickly pointing at someone else.)