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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
