On Tue, April 3, 2007 2:39 am, [EMAIL PROTECTED] wrote:
> For say, Zend_String, the interfaces and abstracts are around what one
> would expect. Main difference though which might cloud the connection is
> that a string can contain multi-byte characters so the method names
> referring to the "byte" wouldn't be completely suitable. You can imagine
> the String classes also needing a wrapper to allow for mbstring functions
> to replace use of substr() and other such non-multibyte friendly functions
> where required (likely a user option since mbstring support varies across
> those troublesome shared hosts).
Well, I was thinking:
Zend_String_Parser extends Zend_Parser_Abstract
Zend_String implements Zend_Parser_DataSource_Interface
Zend_String_Multibyte extends Zend_String
The actual read methods are implemented by the data source objects, so one
parser would work for both. Zend_String_Parser and Zend_String would be
easy (Willy's already done much of the work), but Zend_String_Multibyte
would be a job in and of itself, if it wasn't stipulated to be dependent
on mbstring and/or iconv.
I'm not sure how it should work in cases where you are parsing a binary
file and come across certain bytes that are, for instance, Unicode. I
guess something like
$string = new Zend_String_Multibyte($bytes, 'UTF-16LE');
isn't too awkward.
> Would it be possible to generalise the method naming from readByte,
> skipByte, etc., to a simple read(), skip() style? Similarly Zend_File
> shouldn't be specifically for binary files IMO. Strings can be either a
> PHP string type, or a file resource (from fopen() for example).
> Distinction needs to be made between a binary or plain text file in the
> hierarchy since both types are not truly interchangeable without a little
> abstraction of the read methods.
Yeah, that's probably a good idea. Implementation specifics can be
documented.
> Sorry if I'm poking at this with a stick ;). I know the immediate need is
> for binary parsing and Zend_String or whatever is down the line a ways
> even in terms of a Proposal.
No, thinking about stuff like this now is great, so we don't have to
refactor down the line. :-)
-Matt
