On Sun, Apr 3, 2011 at 11:55 PM, Jonathan S. Shapiro <[email protected]> wrote:
> An interface must be planned for by the developer of the object, because > "this object implements interface I" is part of its declaration. This is not > true of type classes. In objective-c (and possibly smalltalk) there is a thing called categories, from which java derived interfaces, this property does not hold. categories have 2 major uses: as a way to extend an object (provides full access to all of the variables in a way type classes do not). as a way to organize your sources units, it uses a 3rd mechanism (protocols) for saying 'there is a list of methods x,y, and z to which i conform'. This can also be a part of a category. > An interface (at least in Java and C#) has an implicit "this" pointer, and > its members can therefore have integrity-privileged access to the underlying > object. This is not true of type class methods. this is true of objective-c categories. If I may diverge, I guess what I find interesting about this discussion is how relevant it is to the project which brought me to know about BitC. basically the GNUstep-base Foundation and AppKit libraries, are split into 2 shared libraries, the graphical and non-graphical classes. the non-graphical (Foundation) library was about 4 times the size of a little embedded device I wanted to run a little client/server thing on, so I wanted to share code from the client and the server like a good boy. so, I was splitting all of the classes (which are largely just using inheritance), into their own seperate shared libraries specifying explicit dependencies, while using categories/protocols to break dependencies when possible. the hardest part about this, is all of the interdependencies that had crept in to the code over ~10+ years. these had to be made into explicit mechanisms which could be used when separated out into individual shared libraries. for ease of writing test cases, I planned to split the mechanisms/graphical/event processing and add a mechanism where all of these intersect. into separate pieces, so 'make test' wouldn't have to launch a ton of windows, just to test the mechanisms. from the outside/porcelain, it presented a traditional inheritance API, and the inside was using a type-class like mechanism throughout, and special purpose inter-object communication API's, I considered this essential, because when you want a button, you just want a button, you don't want to have to combine a 'logical button', with a 'graphical button', with a button event processor. I'm not going to say it's impossible with type classes but without inheritance, I'd really have to get a few thousand lines of code in and see how it turns out. but like shap I have somewhat of an interest in at least modeling something in bitc based loosely on a system of inheritance (while I was rewriting the whole darn thing, I thought that I might as well make it a capability system which lead me to coyotos which lead me to bitc). sorry for the length. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
