Bruce McFarling <agila61@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> > So you do your IF every time the code executes.
>
> But if there is an OO system in place, then it optimizes that
> selection. And that can be designed so it works equally well in the
> interpreter as the compiler, so there's no need to go into a state-
> smart word that only works in a compiler.
You wave your hand and say it gets a state-smart result without being
state-smart.
But of course there are ways to get good results, and if you're going to
re-use the object-creating code a whole lot then it's worth a lot of
effort to get it smooth.
> Where that to> and from> starts to break down is exactly where you
> pinpointed it as a potential convenience ... where it is smart enough
> to work out the type of the thing it is storing to.
Yes.
> However, suppose that you have a structured data item, and you need a
> different to> and from> for each different structure ... sometimes it
> copies a pointer, because the underlying data is persistent, sometimes
> it copies the whole structure, because the underlying data is dynamic,
> sometimes it copies a pointer and updates a pointed-to count for a
> garbage collector.
Ouch. When you know at compile-time what structure it is, then you're
fine. When you expect to get an adequate result for every possible
combination of object types it might somehow be presented with, then
you're committing hubris.
> Instead of putting more and more intelligence into to> and from> ...
> you package that structured data together with precisely the to> and
> from> that works with *that* structure, so it does not need to know
> that any other to> or from> exist and you never have to *extend* an
> already working set of to> and from> ... just write a new one.
Yes, I thought that was obvious. In the sample Forth code Douglas
presented, to> and from> were only constants. You can use those
constants to point into a jump table or a linked list or whatever, and
they don't tell you *anything* about what you'll find when you get
there. You decide that when you decide which linked list etc it is
you're going to let them point into.
> You have multiple data structures of a given type but only one set of
> functions working on them, so you have store the data structure
> creating code and the functions working on the data together, since
> you only need either of them to show up once, and the data structure
> only needs to be able to get back, somehow, to the set of functions
> that work on it.
Sure. One TH is enough for every array that uses cells. One NAME-FIELD
is enough for every data structure that puts its name field in the same
place. And objects give you a way for the computer to track all that so
you don't have to. If you can avoid combining types where you can't
predict how to do it at compile time, then you can move all that
information into the editor and keep it out of your runtime code. It
turns into a sort of database that's a convenience to you.
> So you have an elaborated version of one creating word and multiple
> created words, except instead of one action you have a system of
> actions dedicated to that data structure.
Sure. And once you have thousands of different kinds of objects with a
bewildering assortment of combinations of methods, you desperately need
some sort of database to even keep track of them. Somewhere before I get
to this point I start to get the impression I've made some kind of
mistake. I must be solving the wrong problem, or it wouldn't have gotten
to this point.
> Then after getting that, you notice that sometimes you extend a data
> structure, so you are rewriting to> and from> but it is based on the
> original data structure to> and from> ... so you develop a system
> where you can copy the original data structure and then extend it, and
> a system where you can get the working to> and from> from the original
> and extend them, rather than writing them from scratch.
Oh, yes. So say you have some methods the same but other methods
different. You want to first check the new ones, and then check the
inherited ones later. And it's better to check the original copies of
the inherited methods than make copies, because that way if you decide
to change the originals then everything will be changed at once. On the
other hand, if each one points to the actual code, then you can look for
things in the order of their frequency of use and find them faster on
average. You don't have to first check this object's methods, and then
the methods of its immediate ancestor, and then that one's ancestor, and
back up the chain.
> OK, that enhanced create/does> word is a class, that created data
> structure that has its own collection of specific operations is an
> object or instance, and the process of making an extended version of
> an existing enhanced create/does> word is called class inheritance.
Sure.
> Its just a collection of solutions to a specific style of programming
> problem, packaged together so that each piece is optimized to work
> with each other piece, and given terminology to make it simpler to
> talk about it.
The impression I have so far is that when that's simple enough to do
easily, you can easily do without it too. What it's good for is dealing
with extreme complexity. And then you need great skill to do it well.
Because if you do it poorly it will give you extra complexity to deal
with instead of hiding the original mess.
This reminds me of a project I started when I was new to Forth. I was
making a strategy game where each side had a lot of ****ps that were much
slower to turn than they were to move forward. So it was usually slow to
try to move them into formations. And while each robot ****p would mostly
follow its orders or follow predetermined strategies you gave it, it
also had its own prior programming that took precedence. ****ps would
refuse to follow obviously suicidal orders. I had a graphical design
language set up to tell the ****ps what to do given patterns of other
****ps around them. And I had it set up so it could be played over slow
modems over phone lines, slow but without the variable delays of the
modern internet. So I wanted the messages from one side to the other to
be short, and the game computers it would play on had limited memory,
and I wasn't sure which items could be bytes and which needed to be
cells. To make it easy to change that I made each special type be a sort
of object. MOVE-DELAY would have MOVE-DELAY@[EMAIL PROTECTED]
and MOVE-DELAY! which could
be set to either C@[EMAIL PROTECTED]
C! or @[EMAIL PROTECTED]
! etc. It was simple to write a system that
made the commands by default when I declared a variable or array.
So I had this system all set up so I didn't have to know the types of my
items, and I had various other things to speed it up and particularly to
speed up information flow across the bottleneck. And then I found that
there was a fundamental flaw in the game design, so that ****p strategy
didn't work the way I thought it should. I'd put so much effort into
preventing later problems that I misunderstood something fundamental.
I'd have done better to make a quick prototype to play strategy games
on, and then modified it later at need.
|
