Talk:Classes: Difference between revisions

1,098 bytes added ,  12 years ago
no edit summary
No edit summary
Line 82:
 
Take this with a large grain of salt; this needs to be done carefully to avoid ending up in data type hell. It certainly shouldn't be used recklessly. Like I said, it's not really OOP, just an imitation that allows for some OO design principals to be applied. --[[User:Bnlott|Bnlott]] 00:12, 2 July 2011 (UTC)
 
::Yes I understand that. It's just sometimes people get too excited and starts abusing some of these techniques. It roughly goes like this, in order:
 
::# "Oooh let's make the struct inheritable" -- make struct foo "has-a" struct bar and extra members, typecast struct foo* to struct bar*;
::# "Oooh let's make it run-time polymorph" -- add function pointers to struct bar; function looks like method(bar *, ...) but clunky when used on foo; fine, change prototype to method(void *, ...)
::# "But inheritance is not convenient?" -- inplement some kind of vtbl, a global table storing method pointers, while first member of foo and bar refer to this table;
::# "But foo's vtbl and bar's vtbl should not be the same?" -- make foo's vtbl an inherited form of bar's; change the method lookup method--
 
::Notice how the problem of polymorphism of foo and bar now includes polymorphism of foo and bar's vtbls, and we have a meta recursion, goto 1, sanity lost. It's not pertinent to the code example or your comments, just some amusing observations. --[[User:Ledrug|Ledrug]] 00:34, 2 July 2011 (UTC)
Anonymous user