Re: Existence Based Polymorphism

On 2 June 2010 12:47, Conor Stokes <[email protected]>wrote:

> Decision tables suffer from two big flaws that virtual functions don't; the
> expression problem (you can add a new class that implements a virtual
> function without modifying any other code or data)
>

Well, as long as you don't want to be able to create that class at any
point, you're right.
The only thing you have to add in Existence Based Typeing would be creation
(or transition) methods which you need if you're using virtuals anyway.


> and a lack of type safety (although, this could be removed with first class
> support).
>

type safety? if you mean "ensuring that the entity state remains in the same
set of enumerated states on transition", then you're correct, but that's
also a benefit as much as a fear. I can think of a good benefit of
transitioning out of one enumerated set into another: "live-AI state" to a
"memento state" for storing only what is needed so that when the player
comes back within range the AI appears to have been running all the time.


> To do the equivalent to what virtual functions do (execute different logic
> based on the incoming data), decision tables have overhead; usually a
> similar overhead to a virtual function (because they're usually a table of
> function pointers),
>

Decision tables aren't tables of function pointers ever. If you mean switch
statements, then you're missing out on what a decision table means; it's
more about providing zero or more reactions to an incoming data stream. They
don't work on incoming streams of data then shunting off into other code,
they merely provide a mechanism by which you can process what should be done
given an incoming stream of state information. This does in turn lead to
good possibilities for state transition engines, which is why I say it's
stronger than virtual function oriented polymorphism, but the technique
never actually hits logic as the arguments for the decision tables to work
on are produced by processing the potential set, and the outputs are used to
built a processing set. What the processing is on either side of a decision
table processing stage is arbitrary.


> although they might have better cache locality for the table lookup (not if
> you have a big table obviously),
>

I've come up with a solution to the problem of large tables that literally
just involves using a tri state bool for the argument comparison. It's very
hard to make that table big enough to not fit in cache.


> they're not going to gain you much in terms of the code cache.
>

there's hardly any code to run on a decision table, all you're doing is
converting arguments to decisions.


> They are both tools with certain roles and they both have a place in a
> large codebase that does many different things.
>

I think we can still maintain that OO virtual function driven development is
good for very high level development where abstraction is paramount.

I have a feeling our definitions of decision tables aren't quite in
alignment, I only learnt about the term a few months ago, so I may be using
it wrong, but here's how I understand it:

http://www.methodsandtools.com/archive/archive.php?id=39
http://en.wikipedia.org/wiki/Decision_table

worthy of  note is that in most cases, output from a decision table is not
limited to 1 decision, it can be anywhere from zero upwards.

-- 
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com