Talk:Classes: Difference between revisions
Content added Content deleted
| Line 61: | Line 61: | ||
--[[User:Bnlott|Bnlott]] 22:59, 1 July 2011 (UTC) |
--[[User:Bnlott|Bnlott]] 22:59, 1 July 2011 (UTC) |
||
::Well sort of. For you code to compile, the compiler has to know how to dereference <code>bar->new</code> to begin with, meaning the type is already known, so it's not polymorphism by type. You can change function pointers on each instance, so it is dynamic dispatch per instance at run time. The value of this can be questioned: how is this better than storing relevant attributes in the struct, and let handler functions do different things accordingly? (note: it can be different, I'm just saying you have to think about it before designing such an interface--syntax sugar, if sugar at all, may come with drawbacks). Secondly, things like inheritance is still not supported at language level, if you want to add a new attribute and a new method to bar, the struct definition need to be changed, existing methods need to be type-coerced, you need to do a lot of type casting using them, and code becomes a mess real fast. And because each instance has its own function pointers, when you create a new instance, you now need to remember to copy all of them, at each level of inheritance, in correct order, etc. You main() function may look more "OO" like, but it's not sustainable when you need to extend it. The real question is, if you <i>need</i> OO, why use C? --[[User:Ledrug|Ledrug]] 23:32, 1 July 2011 (UTC) |
::Well sort of. For you code to compile, the compiler has to know how to dereference <code>bar->new</code> to begin with, meaning the type is already known, so it's not polymorphism by type. You can change function pointers on each instance, so it is dynamic dispatch per instance at run time. The value of this can be questioned: how is this better than storing relevant attributes in the struct, and let handler functions do different things accordingly? (note: it can be different, I'm just saying you have to think about it before designing such an interface--syntax sugar, if sugar at all, may come with drawbacks). Secondly, things like inheritance is still not supported at language level, if you want to add a new attribute and a new method to bar, the struct definition need to be changed, existing methods need to be type-coerced, you need to do a lot of type casting using them, and code becomes a mess real fast. And because each instance has its own function pointers, when you create a new instance, you now need to remember to copy all of them, at each level of inheritance, in correct order, etc. You main() function may look more "OO" like, but it's not sustainable when you need to extend it. The real question is, if you <i>need</i> OO, why use C? --[[User:Ledrug|Ledrug]] 23:32, 1 July 2011 (UTC) |
||
:::You are correct when you say that this isn't the most convenient thing ever. For this to have anything like true polymorphism, the code will either become messy or dangerous (possibly both). While you are correct that you shouldn't be using C if you really need OO, things like this can make you life easier. Consider a contrived example: you have a DB access layer like Perl's DBI or Java's JDBC. You could have something like: |
|||
<pre>struct DB_access{ |
|||
+ bool:connect() |
|||
+ char**:getData() |
|||
+ void:disconnect() |
|||
} |
|||
mysql_connect(); |
|||
sqlite_connect(); |
|||
/* etc... */ |
|||
mysql(); |
|||
sqlite(); |
|||
struct DB_access * DB = sqlite(); |
|||
struct DB_access * DB = mysql();</pre> |
|||
The idea behind switching the function pointers around is to avoid the switch/case and if/else blocks that can result from trying to make single functions handle things differently. This hardly gives you access to all of the capabilities that true OO languages provide, but it does allow for many of the OO design principals to be applied in C. |
|||
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) |
|||