I'm thinking of creating a Document-based app for my pet project. And I'm
thinking about how to read the data in. I could load all the data, change it to
a string, then process it; but I want to process the data in layers and do some
work before string conversion. Specifically, I want to handle line breaks at
the binary-data stage. Whatever I'm going to use will handle CR, LF, and CRLF.
In my head, I came up with (in Swift):
//=====
import Foundation
@objc
public enum LineReadingEnding {
case None
case LfOnly
case CrOnly
case CrLfPair
case LfCrPair // to eliminate spurious line breaks
}
@objc
public protocol LineReadingDelegate {
public delineateDataFromReader(reader: LineReader, data: NSData, ending:
LineReadingEnding)
}
public class LineReader: NSObject {
public var delegate: LineReadingDelegate?
public func lineateData(data: NSData)
public func flushDataCallingDelegate(callDelegate: Bool)
}
//=====
You pipe your data through "lineateData." (Since NSFileHandle and NSInputStream have
NSData-related methods, you can pipe through those sources too. I originally had a direct function,
but switched to a class plus delegate to support these cases.) I certainly get a line after a CRLF
(or LFCR), but you need "flushDataCallingDelegate" to get the last line, especially if
the last line isn't capped. Either call sends as many lines as possible to the delegate per call.
(The data given to the delegate does not have the ending bytes attached.)
I have the algorithm in mind for the parsing, then realized that the handling needed to wait
for the single line-break characters in case a paired character followed may be generalized. So
I would add another property for a "Set<NSData>" of all possible line breaks.
However, I would need a parse tree, for the cases where some sequences are initial-subsets of
others. Am I making it too complicated?
It would make a nice challenge, though. Though quick web-searches, I haven't
seen any code applicable (or applicable enough), especially since the libraries
tend to be NSString (instead of NSData) oriented. At least other people don't
have to worry. I'm thinking of making this version on Objective-C, to be closer
to the metal, and easier compatibility (since Swift is still in flux and needs
to drag in libraries).
Sent from iCloud
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
