Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23098
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4457E5CE.3000009@filemobile.com>
Date: Wed, 03 May 2006 01:05:50 +0200
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Marcus Boerger <helly@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <44572F67.9050807@php.net> <B1DAA5C9-7F01-4E68-9205-3FE1CD2C8D65@prohost.org> <4457D88D.3000505@filemobile.com> <115250268.20060503003818@marcus-boerger.de>
In-Reply-To: <115250268.20060503003818@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] php 5.2.0
From: evert@filemobile.com (Evert Pot)

Hi Marcus,

Thanks for your quick response. First I need to say I'm not really 
trying to compare this with the PHP streams wrappers.. the streams 
wrappers do a lot more than just streaming bytes, they even know about 
files and directories...

Marcus Boerger wrote:
> XMLReader/XMLWriter have nothing to do with our streams implementation
> though they can leverage them. In fact they follow libxml2's api which
> is inspired by C#'s xmlTextReader. Adding functions to that doesn't make
> sense at all they are just wrappers that make the libraries api available
> to PHP. SPL could be the start of such a thing but right now in no way is
> limited to streams stuff. Again it can leverage streams of course and
> that at any level.
>
>
>   
If XMLReader/XMLWriter would work with this streams API, it would allow 
me to pass it through filters before writing/reading from a base stream 
object.. Because everything implements those interfaces, the 
XMLReader/XMLWriter doesnt have to know exactly what it is being fed 
(either a base-stream or a stream decorated by 1 or more filters)
>> This implementation is just a suggestion (and I really like the 
>> flexibility of the Java IO system).. I'm just really missing a proper 
>> unified stream system..
>>     
>
> Flexibility of the cost that it takes a decend programmer years to
> understand what plays together in what sense...definitively the
> opposit of php's kiss approach.
>
>   
I definitely agree on this one.. the api that a developer would use now 
wouldnt have to change and should not become more complicated.. but 
there are also power users..

The eventual API doenst have to look that difficult.. I'm thinking of 
something like :

$file = new FileReader('filename'); // to read just bytes
$file = new HTMLFilterReader(new FileReader('filename')) to filter the html

Writing to a file would work in the exact same way..

>> Great work has already been done to centralize systems because of the 
>> introduction of the Traversable interface and its descendants.. but more 
>> and more often I find myself rewriting PHP extensions in PHP, because 
>> there's no unified (abstracted) API..
>>     
>
> Traversable is a tag necessary to the engine and does not define any API.
> The corresponding API is being defined by the two interfaces Iterator and
> IteratorAggregate. None of those has anything to do with reading streams.
> All that occurs is that SPL gives you a class (SplFileObject) that
> simplifies reading files line by line wchih is based on Iterator, giving
> it a semantical meaning.
>
>   
The point i tried to make was, because of traversable and its 
descendants, we now can now do a simple thing like :

if ($var instanceof Traversable) echo('And we know we can iterate over 
this object, regardless of the class..');

in the same manner:

if ($var instanceof Writer) echo('Now we know we can call the write() 
method');
>> I'm already pretty far in implementing this in PHP, and I would be more 
>> than happy to PEAR it (if people are interested).. but I feel like a 
>> system like this belongs at the core to prevent every new subsystem from 
>> figuring out a new API...
>>     
>
> If you go with such classes be sure to follow established naming conventions
> and do not name them simply 'BufferedReader' or even worse 'Reader'.
>
>   
I used simple names to easily illustrate what i wanted to do.. Java uses 
the same conventions since Java 1.1.
>> I hope I made my point, I'll be more than happy to eloborate or help 
>> writing specs for this system, my C skills are mediocre though..
>>     
>
> Streams stuff belongs here. You don't want to wait forever when reading
> giles do you? However having a pear like, working set of classes interfaces
> would be a nice starting point. So your work would be of help of course.
>
>   
I'll be happy to put it in PEAR, although this doesn't give me the power 
I would love to have.

Thanks again,
Evert