4 ms·
We don't need "modern" UI frameworks we need well designed UI frameworks. HTML isn't designed for stateful UIs. I'm hoping that Cocoa will eventually move awa
by richcollins 15y ago
We don't need "modern" UI frameworks we need well designed UI frameworks. HTML isn't designed for stateful UIs. I'm hoping that Cocoa will eventually move away from Objective-C and towards a more dynamic (expressive) language (Javascript would be great).
- coliveira 15y agoA major problem with web-based UIs is the lack of sane defaults. The default for HTML is a document with basic formatting. You need somebody with good design skills to create an App that doesn't look awful. On the other hand, frameworks such as UIKit provide all you need for a nice-looking UI. Developers just need to worry about the application code, and worry about UI design much later in the process.
- programminggeek 15y agoHave you looked at this? http://cappuccino.org/ http://cappuccino.org/ It's basically Cocoa on javascript using Objective-J
- richcollins 15y agoI like cappuccino the framework but not Objective-J the language. It mostly takes the bad parts of Objective-C and puts them on top of Javascript (with the exception of "forward")
- Zev 15y agoBy "dynamic" do you mean "interpreted"? Because Objective-C is a pretty dynamic and flexible language, otherwise.
- richcollins 15y agoObjective-C does have performSelector, but its awkward to use. It lacks the ability to easily add slots to objects and you often have to work with C types. Perhaps "expressive" would be a better distinction. Javascript is a much more expressive language, meaning that I have to do a lot less work to accomplish the same end.
- bonch 15y ago> Objective-C does have performSelector, but its awkward to use. It lacks the ability to easily add slots to objects and you often have to work with C types. -performSelector: takes a selector string, and its variants allow you to pass objects as arguments. I'm not sure why you think it involves C types or why you cite it as the feature that makes Objective-C dynamic (there's considerably more to it than that).
- richcollins 15y agoI was talking about Objective-C not performSelector, although performSelector does illustrate some problems with C types. You can't return a value with perform selector precisely because of C types (unless you wanted performSelectorReturningInt ... etc)
- bonch 15y agoObjective-C is already a dynamic language. Its ability to drop to low-level C at will makes it too flexible and powerful to abandon for something slow and cumbersome like Javascript.
- richcollins 15y agoWhich is more cumbersome? //Objective-C #import <Foundation/Foundation.h> @interface Order : NSObject { NSString *id; Customer *customer; NSDate *timestamp; NSString *productId; } @property (nonatomic, retain) NSString *id; @property (nonatomic, retain) Customer *customer; @property (nonatomic, retain) NSDate *timestamp; @property (nonatomic, retain) NSString *productId; @end #import "Order.h" @implementation Article @synthesize id; @synthesize customer; @synthesize timestamp; @synthesize productId; - (void)dealloc { [self setId:nil]; [self setCustomer:nil]; [self setTimestamp:nil]; [self setProductId:nil]; [super dealloc]; } //Javascript Order = Proto.clone().newSlots("id", "customer", "timestamp", "productId");
- bonch 15y agoObjective-C is always going to win the contest for Smalltalk-esque verbosity, but I would hardly consider the code you wrote to be cumbersome. In the modern Objective-C runtime using garbage collection, you can write this: // Order.h #import <Foundation/Foundation.h> @interface Order : NSObject @property (copy) NSString *id; @property (retain) Customer *customer; @property (copy) NSDate *timestamp; @property (copy) NSString *productId; @end // Order.m #import "Order.h" @implementation Article @synthesize id; @synthesize customer; @synthesize timestamp; @synthesize productId; @end Apple engineers have confirmed that they're working on making @synthesize the default behavior for properties, so eventually you won't have to write that either. A real-world app would be using Core Data for its model objects, negating the need to write this class at all while adding automatic faulting, data integrity, and undo/redo: Order *order = [NSEntityDescription insertNewObjectForEntityForName:@"Order" inManagedObjectContext:self.managedObjectContext];