Doug Hoffman <no.spam> wrote:
> Jonah Thomas wrote:
> > I've consistently avoided OO. I've tried to avoid problems that are
> > complicated enough for OO to be valuable.
>
> That's similar to trying to avoid using create/does>. Yes, there is
> some extra complexity. But in some, not all, problems it is very
> worthwhile.
> \ **First let's use create/does>
>
> 0 constant to>
> 1 constant from>
>
> \ assumes 4 byte cell
> : CDobject \ create/does> object factory
> create 4 allot
> does>
> >r
> IF ( from>) r> @[EMAIL PROTECTED]
ELSE ( to>) r> ! THEN ;
>
> CDobject x
> ok
>
> 45 to> x
> ok
>
> from> x .
> 45 ok
So you do your IF every time the code executes.
That overhead could be reduced.
: CDobject
create 0 ,
does> POSTPONE LITERAL IF POSTPONE @[EMAIL PROTECTED]
ELSE POSTPONE ! THEN ; immediate
0 constant to> immediate
1 constant from> immedidate
Now the overhead is moved to compile time. But you can't test your code
in interpret state, it's gone compile-only. So make it state-smart....
Or better yet, you could turn your editor into some kind of
preprocessor. It saves your source code but it also makes a different
source code for the compiler to try. The original source code would be
your OO code, and the intermediate source code would be traditional
Forth.
So you write "to> x" and the editor translates that to "x !" and it's
all good.
And what you get for your trouble is you can say
45 to> x in place of 45 x !
At first sight it's hardly worth it. But your example was simple. You
could have made a CDobjectD which did 2@[EMAIL PROTECTED]
and 2! inatead, and another
that did F@[EMAIL PROTECTED]
and F! and one that did c@[EMAIL PROTECTED]
and c! . Then you only have to
keep track of the data types when you create the object. So to> and
from> work the same for all the different datatypes. Of course you still
have to know about double or floating objects because they have very
different stack effects. It would be a great big effort to create object
operations that would work for everything, so you didn't have to keep
track of types. But it could be done, and it would be something of a
convenience.
> \ **Now let's use objects
>
> :class OOobject \ OO object factory
> 4 bytes data
>
> :m to: ( n -- ) self ! ;m
> :m from: ( -- n) self @[EMAIL PROTECTED]
;m
>
> ;class
>
>
> OOobject y
> ok
>
> 45 to: y
> ok
>
> from: y .
> 45 ok
Almost the same thing. But that "self" command looks good. If the DOES>
could use xt COMPILE, in place of LITERAL it would be more efficient.
> Of course with objects we can do a lot more than create/does>. I
> won't not go into all of that here.
Sure. I saw that you can use the same exact to: from: commands for all
the different datatypes and have them do different things. And you can
make new modifiers that only work for some objects and throw errors for
others. You could have a chain of tests. So an object modifier can do
219 constant funny:
And then your object first looks for #219 in its own list, and then
calls another object list and looks for it there, and then another and
another until it either finds something that handles that behavior or it
runs out of places to look. So you don't have to list all the behaviors
in one place.
> Has create/does> failed? I don't think so.
It depends on your purpose. IF the intention was to correctly handle a
whole lot of details so you don't have to know about them, it will very
likely fail. As soon as you try to do something that you didn't plan for
when you built the objects, then you have to go back and figure out how
they worked well enough to add to them correctly. If something goes
wrong then you aren't just debugging your program, you're debugging your
objects too. It looks to me like this sort of thing will be particularly
valuable when you have a big complicated problem that a lot of people
will be dealing with. Say you get one great programmer who devotes say
a year to creating an object system that hides a lot of the complexity,
and you get perhaps hundreds of programmers using it over the years, and
the great programmer's attention to his objects goes from full-time to
half-time to eventually less than 1/10 time as the system matures and
increasingly meets all the users' needs.
> What if someone had hyped create/does> as the "Magic Silver Bullet"
> that would solve all of your programming problems? You and I both
> know that is not true. But does that mean create/does> has no value
> and we should now abandon it? I don't think so.
create/does> is pretty simple, and it does something that some people
find useful. I wouldn't recommend abandoning it unless we find something
that's simpler or more powerful or better, both.
Again, what does CREATE DOES> do? It lets you take a particular action
and associate it with an address, and the same action can be associated
with a whole series of addresses. Many-to-one. It does nothing the other
direction, associating multiple actions with one address, and to do that
you used an IF for two actions and presumably a CASE for many. Any place
you use a DOES> child you could use 'address action' instead. Two words
in place of one. Or you could use colon definitions to get a similar
effect.
It looks to me like objects are very useful in a limited domain, and can
be made to work with a lot of effort in a much larger domain. They will
be mostly replaced by something that's conceptually simpler when the
time is ripe. I think the time is ripe now, but I haven't seen the
simpler and more powerful system to replace them. We're ripe for it.
Where is it?
|
