I just tried it with a vanilla, freshly downloaded ndk-r8d and a small Objective-C program compiled without problems, so it looks like my hunch was correct.
Of course, it didn't link because there is no runtime, but providing one is a much smaller effort than reconfiguring the entire toolchain. After that, it gets interesting...
Update: after getting a runtime, it linked and ran on my Galaxy II test phone.
I am sure it'll be fun and hope it will be instructive. If you're interested, give Stefanie a shout!
Update: December was a bit optimistic for all involved, so we're tentatively moving this out to the beginning of March. I'll post the exact date once it has settled.
[myButton setEnabled:YES] from a background thread
so it will execute on the main thread.
Alas, the obvious [myButton performSelectorOnMainThread:@selector(setEnabled:) withObject:(BOOL)YES waitUntilDone:YES]; is not only ugly, but also doesn't work.
It used to kinda sorta work for scalar integer/pointer parameters that fit in a register, but it
certainly wasn't a good idea and started breaking when Apple started to retain those parameters.
Casting a BOOL to a pointer and back might work at times, sending it a retain will definitely not.
What to do? Well, I would suggest the following:
[[myButton onMainThread] setEnabled:YES];
@interface NSObject(asyncMessaging)
-async;
-asyncPrio;
-asyncBackground;
-asyncOnMainThread;
-onMainThread;
-asyncOn:(dispatch_queue_t)queue;
-asyncOnOperationQueue:(NSOperationQueue*)aQueue;
-afterDelay:(NSTimeInterval)delay;
@end
HOM_METHOD(onMainThread)
[invocation performSelectorOnMainThread:@selector(invokeWithTarget:) withObject:self waitUntilDone:YES];
}
With Ruby now at about 20% of the Objective-C popularity ratings (whatever those mean), maybe there is room to extend the Objective-C stack to the web? Especially as we are experiencing a shift in technologies from MVC frameworks to REST backends.
After all, we had this in the past, with core object models bridged to the UI with AppKit, to legacy databases with EOF and to the web with WebObjects. Now we could do mobile, desktop and server with a common, well-tested object model. Some say crafting object models this way is a Good Idea™. Thoughts?
On OSX, we have the Cocoa APIs, which are at least somewhat OO, but on the other hand don't have a real
graphics context, only the stunted NSGraphcisContext which doesn't actually allow you to do,
you know, graphics. Instead we have a whole bunch of "use-once" objects that are typically
instantiated, told to draw themselves to an implicit global drawing context and then discarded. This
seems exactly backwards, I would expect an explicit graphics context that I can use to draw using a
consolidated API.
That consolidated API is only available in the form of the CGContextRef and its associated
functions, but alas that's a C API. So extremely long names, but without named parameters or useful
polymorphism. Despite the fact that a graphics context is a quintessential example of OO, only
Apple can create subclasses of a CGContext, and even then in only a sorta-kinda sort of way: CGBitmapContextCreate returns
a CGContextRef that silently knows how to do things that other
CGContextRefs do not. Same for CGPDFContextCreate.
On iOS, CoreGraphics is really your only choice, and double so if you want code that works on both iOS and OSX, but that means having to put up with the API, constantly converting between UI/NS objects and CoreGraphics and then there's the whole text mess.
Having been a great fan of algorithmic drawing every since my exposure to DisplayPostscript on the NeXT Cube, I found all of this sufficiently unsatisfactory that I decided to work on a solution, the first step of which is a lightweight drawing context that provides a reasonable Objective-C drawing API on top of CoreGraphics and works the same on OSX and iOS.
The result is on github: MPWDrawingContext, embedded in a version of Mark Gallagher's excellent IconApp AppKit drawing example. The same code is also used in the iOS target (a variant of Marcus Crafter's version of IconApp). I've also started using the context in a bunch of my own projects (that was the purpose after all) and so far it's made my graphics coding much more pleasant.
Another advantage, at least for me, is that bridging to scripting languages is automatic due to Objective-C's runtime information, whereas C functions have to have to be bridged separately and maintained, which is burdensome and doesn't necessarily get done.
At least one of Peter's problem with CGBitmapContextCreate is also solved: creating a bitmap context is as easy as
[MPWCGDrawingContext rgbBitmapContext:NSMakeSize(595,842)]| Lines | Characters | Lines % | Characters % | |
|---|---|---|---|---|
| AppKit | 146 | 6593 | 67.12% | 76.69% |
| CGContext | 134 | 7367 | 73.13% | 68.63% |
| MPWDrawingContext | 98 | 5056 | - | - |
Although the slides were primarily supportive and do not necessarily stand on their own, they are now available online by popular request (2.3MB, Keynote).
And a PDF version (6.3MB).
marcel@nomad[~]wrk -c 100 -r 300000 http://localhost:8082/hi
Making 300000 requests to http://localhost:8082/hi
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 4.60ms 2.51ms 11.47ms 62.40%
Req/Sec 14.98k 0.99k 16.00k 52.80%
300002 requests in 9.71s, 21.46MB read
Requests/sec: 30881.96
Transfer/sec: 2.21MB
marcel@nomad[~]curl http://localhost:8082/hi
Hello World!
marcel@localhost[scripts]cat memhttpserver.stsh #!/usr/local/bin/stsh context loadFramework:'MPWSideWeb' server := MPWHTTPServer new. server setPort: 8082. stdout println: 'memhttpserver listening on port ',server port stringValue. server start:nil. scheme:base := MPWSiteMap scheme. base:/hi := 'Hello World!'. server setDelegate: scheme:base . shell runInteractiveLoop marcel@localhost[scripts]./memhttpserver.stsh memhttpserver listening on port 8082 >
30K documents x 10 tags/document x 4 bytes/tag =
300K tags x 4 bytes/tag =
1200 K bytes = 1.2 MB
Even assuming 2:1 bloat due to to overhead gives us 2.4 MB, which should not just fit comfortably into the
RAM of a modern computer or a cellphone, it actually fits comfortably into the L3 cache of an Intel Core i7
with 8-10MB to spare.What about getting that data into RAM? The slowest hard drives (non-SSD) I could find using a quick web search had a transfer rate of better than 48MB/s and a seek time of around 10ms, so the 2.4MB in question should be in memory in around:
10ms + 2.4MB / (48MB/s) =
10ms + 0.05 s =
10ms + 50 ms = 60 ms
So less than 1/10th of a second to read it in, and a moderately fast SSD reduces that to 10ms.EDIT: fixed embarrassing typo (L1 -> L3 cache).
Node.js did really well on tasks that have lots of concurrent requests that are mostly waiting, did OK on basic static serving tasks and not so well on compute-intensive tasks.
Having developed an interest in minimal web-servers, I wondered how Sinatra and, by association, Ruby on Rails would do.
For Sinatra I used the scanty blog engine and the basic "Hello World" example:
require 'sinatra'
get '/hi' do
"Hello World!"
end
rails s"
to start the server. In addition I also had RoR just serving a static file instead of the database-backed blog. All this on my new dev machine, a 2011 MacBook Air with 1.8 GHz Intel Core i7 and 4 GB of DRAM. I also discovered that httperf is a much better benchmark program for
my needs than ab. I used
it with 100 requests per connection, a burst length of 100 and a sufficient number
of connections to get stable results without taking all day.| Platform | # requests/sec |
| Apache | 5884 |
| Sinatra Hello World | 357 |
| Ruby on Rails static page | 312 |
| Sinatra scanty blog | 101 |
| Ruby on Rails blog | 17 |
Is this considered normal or am I doing something wrong?
Alex Payne: I'm constantly surprised at the popularity and success of Objective-C. Almost everyone I know tells the same story about Objective-C: they started learning it and they hated it. They thought it was the worst of C and the worst of dynamic languages. And then eventually, they learned to love it. Most of the time, that software works pretty darn well, so who am I to judge? I'm pleasantly surprised by the continued success of Objective-C, and I think it should be taken as a lesson for the language designers out there.This is echoed by the the first (and as of this writing only) comment to the post:
Alasdair Allan [18 July 2011 10:09 AM] I certainly agree with Alex about Objective-C, when I was initially learning the language I deeply despised it. Now I love it, and think it's one of the more elegant and powerful of the (many) languages I know. Definitely a lesson to language designers, do what you think is right and ignore the crowds. If you are right people will grow to love your language, just as soon as they figure it out.I actually liked Objective-C pretty much from the start, but then again at that time (1986) there simply wasn't anything close that I had access to, and writing an Objective-C pre-processor and runtime on my Amiga was simply more feasible than a C++ frontend or a complete Smalltalk VM.
Modifying the sentiment expressed slightly, I'd say that from a theoretical point of view, I hate Objective-C and think it's a bad joke, a trainwreck. However, from practical experience, I love it and find it's one of the most productive languages out there for actually building stuff. And no, it's not just about the frameworks, as I've used Objective-C in non-NeXT, non-Apple environments where we had to build most of our own frameworks.
So while I support Alasdair's comment, my lesson for language designers is that our theory appears to not be particularly good at predicting reality. In other words: our theory sucks has many research opportunities.
One way to rectify this situation would be to start using CG* structs and functions on the desktop as well. However, this introduces a dependency on CoreGraphics that shouldn't be there for Foundation-based code.
My alternative is to standardize on NSPoint and friends, and map those to their CG alternatives on iOS. That way, I have minimized my dependencies, with only a small header file to pay for it: PhoneGeomtry.h
This is now part of MPWFoundation (on github).
//
// PhoneGeometry.h
// MPWFoundation
//
// Created by Marcel Weiher on 11/11/10.
// Copyright 2010-2011 Marcel Weiher. All rights reserved.
//
#if TARGET_OS_IPHONE
#ifndef PHONE_GEOMETRY
#define PHONE_GEOMETRY
#import <CoreGraphics/CoreGraphics.h>
typedef CGRect NSRect;
typedef CGPoint NSPoint;
typedef CGSize NSSize;
#define NSMakeRect CGRectMake
#define NSMakePoint CGPointMake
#define NSMakeSize CGSizeMake
#define NSEqualPoints CGPointEqualToPoint
#define NSEqualRects CGRectEqualToRect
#define NSIntersectsRect CGRectIntersectsRect
static inline NSString *NSStringFromRect( CGRect r ) { return [NSString stringWithFormat:@"(%g,%g - %g,%g)",r.origin.x,r.origin.y,r.size.width,r.size.height]; }
static inline NSString *NSStringFromPoint( CGPoint p ) { return [NSString stringWithFormat:@"(%g,%g)",p.x,p.y]; }
static inline NSString *NSStringFromSize( CGSize s ) { return [NSString stringWithFormat:@"(%g,%g)",s.width,s.height]; }
#endif
#endif
Rather, the issues we have had with CoreData were additional complexity and more importantly gratuitous dependencies that, at least for our application, were not offset by noticeable benefits.
One of the most significant structural dependencies is that CoreData requires all your model classes to be subclasses of NSManagedObject, a class provided by CoreData. This may not seem like a big problem at first, but it gets in the way of defining a proper DomainModel, which should always be independent. The Java community actually figured this out a while ago, which is why there was a recent move to persistence frameworks supporting POJOs. (Of course, POOO doesn't have quite the same ring to it, and also the Java frameworks were a lot more heavy-handed than CoreData). The model is where your value is, it should be unencumbered. For example, when we started looking at the iPhone, there was no CoreData there, so we faced the prospect of duplicating all our model code.
In addition to initially not having CoreData, the iPhone app also used (and still uses) a completely different persistence mechanism (more feed oriented), and there were other applications where yet a third persistence mechanism was used (more document centric than DB-centric, with an externally defined file format). A proper class hierarchy would have had an abstract superclass without any reference to a specific persistence mechanism, but capturing the domain knowledge of our model. With CoreData, this hierarchy was impossible.
Since we had externally defined file formats in every case, we had to write an Atomic Store adapter and thus also couldn't really benefit from CoreData's change management. When we did the move, it turned out that the Atomic Store adapter we had written was significantly more code than just serializing and de-serializing the XML ourselves.
Another benefit of CoreData is its integration with Bindings, but that also turned out to be of little use to us. The code we managed to save with Bindings was small and trivial, whereas the time and effort to debug bindings when they went wrong or to customize them for slightly specialized needs was very, very large. So we actually ditched Bindings a long time before we got rid of CoreData.
So why was CoreData chosen in the first place? Since I wasn't around for that decision, I don't know 100%, but as far as I can tell it was mostly "Shiny Object Syndrome". CoreData and Bindings were new Apple technologies at the time, therefore they had to be used.
So are there any lessons here? The first would be to avoid Shiny Object Syndrome. By all means have fun and play around, but not in production code. Second and related is to really examine your needs. CoreData is probably highly appropriate in many contexts, it just wasn't in ours. Finally, it would be a huge improvement if CoreData were to support Plain Old Objective-C Objects. In fact, if that were the case we probably would not have to ditch it.
I feel much the same way, that is although I think Grand Central Dispatch is awesome, I simply haven't been able to justify spending much time with it, because it usually turns out that my own threading needs so far have been far more modest than what GCD provides. In fact, I find that an approach that's even more constrained than the one based on NSOperationQueue that Brent describes has been working really well in a number of projects.
Instead of queueing up operations and letting them unwind however, I just spawn a single I/O thread (at most a few) and then have that perform the I/O deterministically. This is paired with a downloader that uses the NSURL loading system to download any number of requests in parallel.
This loads 3 types of objects: first the thumbnails, then article content, then images associated with the articles. The sequencing is both deliberate (thumbs first, article images cannot be loaded before the article content is present) and simply expressed in the code by the well-known means of just writing the actions one after the other, rather than having those dependencies expressed in call-backs, completion blocks or NSOperation subclasses.
- (void)downloadNewsContent { id pool=[NSAutoreleasePool new]; [[self downloader] downloadRequests:[self thumbnailRequests]]; [[self downloader] downloadRequests:[self contentRequests]]; [[self downloader] downloadOnlyRequests:[self imageRequests]]; [pool release]; }
So work is done semi-sequentially in the background, while coordination is done on the main thread, with liberal use of performSelectorOnMainThread. Of course, I make that a little simpler with a couple of HOMs that dispatch messages to threads:
Brent sums it up quite well in his post:
-(void)loadSections { [[self asyncOnMainThread] showSyncing]; [[[self sections] do] downloadNewsContent]; [[self asyncOnMainThread] showDoneSyncing]; } ... -(IBAction)syncButtonClicked { [[self async] loadSections]; }
Here’s the thing about code: the better it is, the more it looks and reads like a children’s book.Yep.
In my last post, I extended Ray Wenderlich's XML parser comparison to MAX, and performance seemed to be about 2x better than the nearest competitor, TBXML and around 7x faster than NSXMLParser, Cocoa Touch's built-in XML parser.
While the resulting code has been posted here, I haven't yet explained how I got there. First, I downloaded both Ray's project and Objective-XML 5.3. iPhone OS requires a bit of trickiness to get a reusable library, partly due to the fact that frameworks or dynamic libraries are not supported, partly due to the fact that simulator and device are not just different Xcode architectures of a single SDK, and not even just different SDKs, but actually different platforms. If anyone can tell me how to create a normal target that can compile/links for both the simulator and the device, I'd love to hear about it!
So, in order to compile for iPhoneOS, you'll need to select the iXmlKit target:
You'll need to build twice, changing Active SDK settings once to the the device and once to the simulator. You will then have two copies of the libiXmlKit.a library, one in the directory Release-iphoneos, the other in Release-iphonsimulator (both relative to your base build directory):
marcel@mpwls[LD]ls -la ~/programming/Build/Release-iphoneos/
-rw-r--r-- 1 marcel staff 521640 May 9 19:52 libiXmlKit.a
These two copies then need to be joined together using the lipo command to create a single library that can be used both with the simulator and the device.
lipo -create Release-iphoneos/libiXmlKit.a Release-iphonesimulator/libiXmlKit.a -output Release/libiXmlKit.a
(Newer Objective-XML versions will have a shell-script target that automates this process). Once I had the fat libiXmlKit.a library, I created a new MAX group in the XMLPerformance project, and copied both the library and the MAX header file into that group:
I then created a new MAX Song parser class:
#import "iTunesRSSParser.h"
@interface MAXSongParser : iTunesRSSParser {
id parser;
NSDateFormatter *parseFormatter;
}
@end
The implementation is also fairly straightforward, with your basic init method:
#import "MAXSongParser.h"
#import "MPWMAXParser.h"
#import "Song.h"
@implementation MAXSongParser
-init
{
self=[super init];
parseFormatter = [[NSDateFormatter alloc] init];
[parseFormatter setDateStyle:NSDateFormatterLongStyle];
[parseFormatter setTimeStyle:NSDateFormatterNoStyle];
MPWMAXParser *newParser=[MPWMAXParser parser];
[newParser setUndefinedTagAction:MAX_ACTION_NONE];
[newParser setHandler:self forElements:[NSArray arrayWithObjects: @"item",@"album",@"title",@"channel",@"rss",@"category",nil]
inNamespace:nil prefix:@"" map:nil];
[newParser setHandler:self forElements:[NSArray arrayWithObjects:
@"releasedate",@"artist",@"album",nil]
inNamespace:@"http://phobos.apple.com/rss/1.0/modules/itms/"
prefix:@"" map:nil];
parser=[newParser retain];
return self;}
The MAX parser is initialized in this init method. We define the elements we care about using the two "setHandler:forElements:inNamespace:prefix:map:" messages, one for each namespace we will be dealing with. In the default (RSS) namespace, we are interested in the "item", "album", "title", "channel", "rss" and "category" elements. In Apple's special "itms" namespace, we will handle "releasdate", "artist" and "album". Setting MAX_ACTION_NONE as the undefined tag action means that the parser will ignore elements not listed as interesting and all their sub-elements.
Songs are created in the -itemElement:... method, which turns the relevant child-elements of the item element into Song attributes:
-itemElement:children attributes:attributes parser:parser
{Song *song=[[Songalloc] init];
[song setAlbum:[children objectForUniqueKey:@"album"]];
[song setTitle:[children objectForUniqueKey:@"title"]];
[song setArtist:[children objectForUniqueKey:@"artist"]];
[song setAlbum:[children objectForUniqueKey:@"album"]];
[song setCategory:[children objectForUniqueKey:@"category"]];
[song setReleaseDate:[parseFormatter dateFromString:[children objectForUniqueKey:@"releasedate"]] ];
return song;}
Two more methods make the actual parse process complete: <channel> elements have one or more <item> elements, so we want to return all of them, using "objectsForKey:":
-channelElement:children attributes:attributes parser:parser{return [[children objectsForKey:@"item"] retain];
}
Finally, there are a bunch of elements that we have defined interest in but treat identically...these can be handled using the "default" element handler:
-defaultElement:children attributes:attributes parser:parser{return [[children lastObject] retain];
}
That concludes the routines that actually parse the XML into objects, now for kicking off the parser. With the timing code removed, the method is fairly straightforward:
- (void)downloadAndParse:(NSURL *)url {
id pool=[NSAutoreleasePool new];
[parserparse: [NSData dataWithContentsOfURL:url]];for ( id song in [parserparseResult] ) {
[self performSelectorOnMainThread:@selector(parsedSong:)
withObject:song waitUntilDone:NO];
}
[pool release];}
With the timing code, it all gets a bit messier:
- (void)downloadAndParse:(NSURL *)url {
id pool=[NSAutoreleasePool new];
[self performSelectorOnMainThread:@selector(downloadStarted) withObject:nil waitUntilDone:NO];
NSData *data=[NSData dataWithContentsOfURL:url];
[self performSelectorOnMainThread:@selector(downloadEnded) withObject:nil waitUntilDone:NO];NSTimeInterval start = [NSDate timeIntervalSinceReferenceDate];
[parserparse:data];
for ( id song in [parserparseResult] ) {
[selfperformSelectorOnMainThread:@selector(parsedSong:) withObject:song waitUntilDone:NO];
}
NSTimeInterval duration = [NSDatetimeIntervalSinceReferenceDate] - start;
[selfperformSelectorOnMainThread:@selector(addToParseDuration:) withObject:[NSNumbernumberWithDouble:duration] waitUntilDone:NO];
[selfperformSelectorOnMainThread:@selector(parseEnded) withObject:nilwaitUntilDone:NO];
[[NSURLCachesharedURLCache] removeAllCachedResponses];
[pool release];
}
This produces a non-incremental DOM-style parser, so we first download the data, then process it into a DOM and finally transfer the processed objects to the main thread for display. It differs from other DOM-syle XML parsers in that it actually produces domain objects (as a Domain Object Model parser arguably should), rather than a generic XML DOM that must then be converted to objects.
Turning the DOM-style parser into a SAX-stye parser is almost completely trivial. Instead of returning the Song objects at the end of itemElement:..
[song setReleaseDate:[parseFormatterdateFromString:[children objectForUniqueKey:@"releasedate"]] ];
return song;}
we instead pass them to the delegate there and return nil so no tree is constructed:
[song setReleaseDate:[parseFormatterdateFromString:[children objectForUniqueKey:@"releasedate"]] ];
[self performSelectorOnMainThread:@selector(parsedSong:)
withObject:song waitUntilDone:NO];
[song release];
return nil;
}
This means we can also remove the "channelElement" method and the for loop in downloadAndParse: that passed the Song objects to the main thread. This is a SAX-style parser (though it doesn't use the SAX methods and does produce domain objects), but it is still non-incremental because it first downloads all the data and then parses it. If we want to turn the SAX parser into an incremental parser that overlaps processing with downloading, there is one final tweak that fortunately further simplifies the downloadAndParse method (again with timing code removed):
- (void)downloadAndParse:(NSURL *)url {
id pool=[NSAutoreleasePoolnew];
[parserparseDataFromURL:url];[[NSURLCachesharedURLCache] removeAllCachedResponses];
[pool release];}
While this is probably best not only in terms of performance and responsiveness, but also in terms of code size, it doesn't play well with the XMLPerformance example, because there are no external measurement hooks that allow us to separate downloading from parsing for performance measurement purposes.
In addition, the XMLPerformance example is odd in that is both multi-threaded and measure real time rather than CPU time when measuring parse performance. The reason this is odd is that when both parsing and display are active, the scheduler can take the CPU away from the XML parsing thread at any time and switch to the display thread, but this time will be counted as XML parsing time by the measurement routines. This is obviously incorrect and penalizes all the incremental parsers, which is why Ray's comparison showed all the DOM parsers as performing better than the SAX parsers.
I hope these explanations show how to create different styles of parsers using MAX.
Ray Wenderlich has done a great comparison of iPhone XML parsers, using the same sample I had looked at earlier in the context of responsiveness.
As Ray was comparing performance, my hobby-horse, I was obviously curious as to how MAX stacked up against all the upstart competition. Quite well, as it turns out (average of 5 runs on an iPad with 3.2):
Figure 1: total times (seconds)
MAX was about 50% faster than the closest competition, TBXML, at 0.43s vs. 0.61s.
However, the XMLPerformance sample is a bit weird in that it measures elapsed time, not CPU time, and is multi-threaded, updating the display as results come in.
In order to account for this overhead that has nothing to do with the XML parsers, I added a "Dummy" parser that doesn't actually parse anything, but rather just generates dummy Song entries as quickly as possible. This takes around 0.2 seconds all by itself. Subtracting this non-XML overhead from the total times yields the following results:
Figure 2: XML parse times (seconds)
When measuring just the XML parsers themselves, MAX is around twice as fast as the closest competition and seven times as fast as the built in NSXMLParser.
Sweet.
[Update] I forgot the link to where I had uploaded the source: XMLPerformance.tgz at http://www.metaobject.com/downloads/Objective-C/
The XML file parsed is the following:
It is parsed using at application startup using the following code:<?xml version="1.0" encoding="UTF-8"?>
<root>
<person>
<name>John Doe</name>
<age>14</age>
</person>
<person>
<name>Mary Doe</name>
<age>14</age>
</person>
<person>
<name>John Smith</name>
<age>15</age>
</person>
</root>
To parse it using MAX you need to add MPWXmlKit and MPWFoundation to your project, and then replace the code above with the following:- (void)applicationDidFinishLaunching:(NSNotification*)notification
{
NSString *path = [[NSBundle mainBundle] pathForResource:@"xmlExample" ofType:@"xml"];
NSData *xmlData = [NSData dataWithContentsOfFile:path];
xmlTextReaderPtr reader = xmlReaderForMemory([xmlData bytes],
[xmlData length],
[path UTF8String], nil,
(XML_PARSE_NOBLANKS | XML_PARSE_NOCDATA | XML_PARSE_NOERROR | XML_PARSE_NOWARNING));
if (!reader) {
NSLog(@"Failed to load xmlreader");
return;
}
NSString *currentTagName = nil;
NSDictionary *currentPerson = nil;
NSString *currentTagValue = nil;
NSMutableArray *people = [NSMutableArray array];
char* temp;
while (true) {
if (!xmlTextReaderRead(reader)) break;
switch (xmlTextReaderNodeType(reader)) {
case XML_READER_TYPE_ELEMENT:
//We are starting an element
temp = (char*)xmlTextReaderConstName(reader);
currentTagName = [NSString stringWithCString:temp
encoding:NSUTF8StringEncoding];
if ([currentTagName isEqualToString:@"person"]) {
currentPerson = [NSMutableDictionary dictionary];
[people addObject:currentPerson];
}
continue;
case XML_READER_TYPE_TEXT:
//The current tag has a text value, stick it into the current person
temp = (char*)xmlTextReaderConstValue(reader);
currentTagValue = [NSString stringWithCString:temp
encoding:NSUTF8StringEncoding];
if (!currentPerson) return;
[currentPerson setValue:currentTagValue forKey:currentTagName];
currentTagValue = nil;
currentTagName = nil;
default: continue;
}
}
NSLog(@"%@:%s Final data: %@", [self class], _cmd, people);
[self setRecords:people];
}
- (void)applicationDidFinishLaunching:(NSNotification*)notification
{
NSString *path = [[NSBundle mainBundle] pathForResource:@"xmlExample" ofType:@"xml"];
NSArray *people=[[MPWMAXParser parser] parsedDataFromURL:[NSURL fileURLWithPath:path]];
[self setRecords:people];
}
… from my (Smalltalk) experience, the block passed to #collect: is often not a single message send, but rather a small adhoc expression, for which it does not really make sense to define a named method. Or you might need both the element and its key/index… how does HOM deal with that?These are certainly valid observations, and were some of the reasons that I didn't really think that much of HOM for the first couple of years after coming up with it back in 1997 or so. Since then, I've become less and less convinced that the problems raised are a big concern, for a number of reasons.
Of course, I wasn't particularly convinced by that line of reasoning, because it smelled too much like "that's not a bug, that's a feature". Until that is, I saw others with less vested interest reporting the same observation:
But are these really limitations? After using higher order messages for a while I've come to think that they are not. The first limitation encourages you move logic that belongs to an object into that object's implementation instead of in the implementation of methods of other objects. The second limitation encourages you to represent application concepts as objects rather than procedural code. Both limitations have the surprising effect of guiding the code away from a procedural style towards better object-oriented design.My experience has been that Nat is right, having a mechanism that pushes you towards factoring and naming is better for your code that one that pushes you towards inlining and anonymizing.
The block syntax is so verbose that there is no hope of actually defining the block inline, the supposed raison d'etre for blocks. So we actually need to take the block out-of-line and name it. So it looks suspiciously like an equivalent implementation using functions:
static NSStringCompareOptions comparisonOptions = NSCaseInsensitiveSearch | NSNumericSearch | NSWidthInsensitiveSearch | NSForcedOrderingSearch; NSLocale *currentLocale = [NSLocale currentLocale]; NSComparator finderSort = ^(id string1, id string2) { NSRange string1Range = NSMakeRange(0, [string1 length]); return [string1 compare:string2 options:comparisonOptions range:string1Range locale:currentLocale]; }; NSLog(@"finderSort: %@", [stringsArray sortedArrayUsingComparator:finderSort]);
Of course, something as useful as a Finder-like comparison sort really deserves to be exposed and made available for reuse, rather than hidden inside one specific sort. Objective-C categories are just the mechanism for this sort of thing:
static NSStringCompareOptions comparisonOptions = NSCaseInsensitiveSearch | NSNumericSearch | NSWidthInsensitiveSearch | NSForcedOrderingSearch; NSLocale *currentLocale = [NSLocale currentLocale]; static NSComparisonResult finderSort(id string1, id string2) { NSRange string1Range = NSMakeRange(0, [string1 length]); return [string1 compare:string2 options:comparisonOptions range:string1Range locale:currentLocale]; }; NSLog(@"finderSort: %@", [stringsArray sortedArrayUsingFunction:finderSort context:nil hint:nil]);
Note that some of these criticisms are specific to Apple's implementation of blocks, they do not apply in the same way to Smalltalk blocks, which are a lot less noisy.
@implementation NSString(finderCompare) -(NSSComparisonResult)finderCompare:(NSString*)string2) { NSRange myRange = NSMakeRange(0, [self length]); return [self compare:string2 options: NSCaseInsensitiveSearch | NSNumericSearch | NSWidthInsensitiveSearch | NSForcedOrderingSearch range:string1Range locale:[NSLocale currentLocale]]; } @end NSLog(@"finderSort: %@", [stringsArray sortedArrayUsingSelector:@selector(finderCompare:)]);
This means that in Objective-C, we already have the ability to do all the iterating we need, mechanisms such as blocks and HOM are mostly conveniences, not required building blocks. If we need indices, use a for loop. If we require keys, use a key-enumerator and iterate over that.
In fact, I remember when my then colleagues started working with a enum-filters, a HOM-precursor that's strikingly similar to the Google Toolbox's GTMSEnumerator+Filter.m. They really took to the elegance, but then also wanted to use it for various special cases. They laughed when they realized that those special-cases were actually already handled better by existing C control structures such as for-loops.
That's not to say that do:, collect: and friends were not light-years ahead of Algol-type control structures, they most definitely were and still are. Having some sort of higher-order mechanism is vastly superior than not having a higher-order mechanism. I do wish that "higher order mechanism" and "blocks" weren't used as synonyms quite as much, because they are not, in fact, synonymous.
When I first encountered Smalltalk blocks, I had just previously been exposed to Backus's FP, and that was just so much prettier! In FP functions are composed using functionals without ever talking about actual data, and certainly without talking about individual elements. I have always been on the lookout for higher levels of expression, and this was such a higher level. Now taking things down to "here's another element, what do you want to do with that" was definitely a step back, and quite frankly a bit of a let-down.
The fundamental difference I see is that in Smalltalk there is still an iteration, even if it is encapsulated: we iterate over some collection and then execute some code for each element. In FP, and in HOM, there is instead an aggregate operation: we take an existing operation and lift it up as applying to an entire collection.
This difference might seem contrived, but the research done with the HANDS system demonstrates that it is very real:
After creating HANDS, I conducted another user study to examine the effectiveness of three features of HANDS: queries, aggregate operations, and data visibility. HANDS was compared with a limited version that lacked these features. In the limited version, programmers were able to achieve the desired results but had to use more traditional programming techniques. Children using the full-featured HANDS system performed significantly better than their peers who used the limited version.I also find this difference to be very real.
The difference between iterating with blocks and lifting operations to be aggregate operations also shows up in the fact that the lifting can be done on any combination of the involved parameters, whereas you tend to only iterate over one collection at a time, because the collection and the iteration are in focus.
With block-based higher order mechanisms, on the other hand, we must make the argument an anonymous function (that's what a block is), and we cannot use a named function, bringing us back to the conundrum mentioned at the start that this mechanisms encourages bad code. Not only that, it also turns out that the base mechanism (messages and methods) is different from the higher order mechanism, which requires anonymous functions, rather than methods.
HOM currently solves only the latter part of this asymmetry, making the higher order mechanism the same as the base mechanism, that mechanism being messaging in both cases. However, it currently cannot solve the other asymmetry: where blocks support unnamed, inline code and not named code, HOM supports named but not unnamed code. While I think that this is the better choice in the larger number of cases, it would be nice to actually suport both.
One solution to this problem might be to simply support both blocks and Higher Order Messaging, but it seems to me that the more elegant solution would be to support inline definition of more-or-less anonymous methods that could then be integrated into the Higher Order Messaging framework.
For the 95% (or more) of code that isn't performance sensitive, it gives you expressiveness very close to Smalltalk, and for the 5% or less that need high performance, it gets you the performance and predictability of C.
