Thoughts on a line-at-a-time data-reading class
Thoughts on a line-at-a-time data-reading class
- Subject: Thoughts on a line-at-a-time data-reading class
- From: Daryle Walker <email@hidden>
- Date: Thu, 10 Mar 2016 07:53:28 +0000 (GMT)
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 (email@hidden)
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:
This email sent to email@hidden