Re: Existence Based Polymorphism

On 2 June 2010 18:05, Conor Stokes <[email protected]>wrote:

>  The typical implementation for a decision table is a compound binary key
> with all the conditional alternatives encoded into a single integer, which
> is then used to lookup the table. The table can obviously then be whatever
> you're encoding your resulting action as (a function pointer representing
> the action to take, an array of function pointers representing multiple
> actions to take, an integer bitflag for a set of actions, a set of
> parameters for another function).
>
> Lex and Yacc use decision tables based on characters and symbols
> (respectively) for the deterministic FSAs they use for parsing (although
> Yacc uses a stack as well). In the case of lexers, part of the action for
> the previous character is used as part of the condition for the next
> decision and this is how sequenced rules are matched.
>
> Cheers,
> Conor
>

Thanks for the great reply. Indeed I do need to specify exactly what I mean
by decision tables, as there is a lot more going on out there than I'd
previously come across. I'd only really noticed them in passing as a
definition of something I was thinking about, but didn't have a name for.
Sorry for the lack of clarity.

I'm going to go and read up on how other people have been using decision
tables (now you've enlightened me further), but in the meantime I'll just
clear up what I mean by decision tables:

Every parameter into the decision table is either yes or no. For
enumerations or floats, the parameter will be the answer to a question about
it (which is what the parameter/argument processing stage is about). I
figured this one because in every situation I've been in, in games
development, everything has at some point come down to an if. If you can
find a way to make a decision with an if, you can provide a bool. Assuming
that the argument list is merely bools, you only need a true/false/dontcare
check for the decision processing stage. Also, I don't do any calling of
code once a decision is made, I merely add it to another stream for later
processing "all in one go", so i still maintain I cache.

I think this definition sits better with the decision tables referenced by
sql business logic, or maybe it just needs to be given a slightly more
specific name. Either way, thanks again for your informative post and I hope
you in turn can get why I think using decision tables like this is actually
cheaper and more flexible than virtuals.

-- 
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