[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: teach your Grandma prototypical inheritance? was (Uncommon OOP in Lua: right or wrong?)
- From: Scott Vokes <vokes.s@...>
- Date: Sat, 25 Sep 2010 12:34:00 -0400
On Sat, Sep 25, 2010 at 11:49 AM, Patrick Mc(avery
<spell_gooder_now@spellingbeewinnars.org> wrote:
> Do you think the idea of using toSort(or a better name) to pack field
> attempts and then taking the first non nil as per the inheritance chain is
> fundamentally flawed?
Not fundamentally flawed, but you'll potentially need a different
lookup chain for every inheritance branch. If you've got something
like this (where "A -> B" means "B inherits from A"):
A -> B
B -> C
A -> D
C -> E
A -> F
then you've got an inheritance lookup table like { B={A}, C={B, A},
D={A}, E={C, B, A}, F={A} }. In typical OO code, this would be built
incrementally with each new definition, rather than one big lookup
table* . If you really want to avoid metatables, you can have the
inheritance-lookup function close over a table you modify, but then
you're explaining closures instead. :)
* though pattern matching has a lot going for it, too. See the
parallel discussion about my tamale library...
> I know your meta table based example is the better code but the programmer has to know what a meta table is.
Not really. As long as you're just trying to teach the big ideas,
you could hide the scary metatable-based details in a library called
"proto" and load the inherit function from that. Or say, "Ignore this
part for now, focus on the concepts", etc.
> I am afraid I am still clueless on how to benchmark my silly example as well.
At a minimum, you can always stick whatever you're benchmarking in a
loop and run it enough that minor time improvements show. Depending on
your OS clock resolution and how long the code takes, running 1,000 -
1,000,000 iterations and comparing os.clock() before and after usually
works. If you want to get more formal, there's great advice here:
http://www.freebsd.org/doc/en/books/developers-handbook/testing.html .
Many details are specific to FreeBSD, but the main ideas (like the
stuff about statistically significant differences) apply everywhere.
Scott