3 ms·
> If anyone remembers, Java had to do OO in a > big-style with OO everywhere -- there were no > alternatives. You can write Java that isn't heavily OO,
by cturner 15y ago
> If anyone remembers, Java had to do OO in a
> big-style with OO everywhere -- there were no
> alternatives.
You can write Java that isn't heavily OO, but you have to implement alternatives to sections of the stdlib that most people assume or take for granted.
Related to what you're saying about the GUI, I'd be interested to see a detailed summary of what the Lighthouse people did, and how it was different to Java. I've found that NeXT tradition stuff - despite claims that it's heavily OO - in facat tends to err away from subclassing towards composition. I suspect the Lighthouse interface patterns did too.
- teyc 15y agoI've struggled through a few Cocoa tutorials. I think the programmer creates a delegate object which handles events. These delegates are assigned to UI elements, similar to how one would addMouseListener to a Java UI element. I may be entirely wrong here. Perhaps someone who knows can put the facts straight.
- hboon 15y agoUI elements typically gets assigned an instance of an object (target) and a symbol representing the object's method (selector). In Cocoa touch, it's: [mybutton addTarget:someObjectMaybeSelf action:@selector(onClick) forControlEvents:UIControlEventTouchupInside]; It's broken into separate methods in Cocoa but it's similar. You don't need to and usually don't create separate classes for targets. The framework usually use delegates when a data source is needed. (for example to build up a table, you need to specify how many rows, what goes into each row etc). Cocoa touch is really clean. Cocoa is still nice but a little messy.