Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28224
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.82.225 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=FRydG/0wUjjBmD3J6qBf61gIauFxHKNDXPpgeos54X9BepKZns6CWNwnAPO4lu6Us2LrTjf+ALWlpVpiim15cOxcUZESwDqrGfRrxGePuGd+zPP9syU+6bA/bKjHTJ8JM7+4oRFAYanzGSRArmqye7AASynUn+bTJ5U4Gn1umgI=
Message-ID: <fe05d1540703040958q62d5d58dkea88924dc0e388b5@mail.gmail.com>
Date: Sun, 4 Mar 2007 18:58:11 +0100
To: "Marcus Boerger" <helly@php.net>
Cc: kingwez@gmail.com, "Arnold Daniels" <info@adaniels.nl>, 
	internals@lists.php.net
In-Reply-To: <26646995.20070304183706@marcus-boerger.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45E33990.8030806@adaniels.nl>
	 <1331353216.20070226232944@marcus-boerger.de>
	 <45E37D05.5040000@adaniels.nl>
	 <408821909.20070303232323@marcus-boerger.de>
	 <fe05d1540703040446u201ce0b7we685bd50808e2c0c@mail.gmail.com>
	 <1508893792.20070304144812@marcus-boerger.de>
	 <fe05d1540703040629j21dc1442k4b2aee57f35d3ed3@mail.gmail.com>
	 <592868326.20070304163838@marcus-boerger.de>
	 <fe05d1540703040922j3d146a5bw7b10009283e02a87@mail.gmail.com>
	 <26646995.20070304183706@marcus-boerger.de>
Subject: Re: [PHP-DEV] suggestion SplFileInfo
From: pierre.php@gmail.com (Pierre)

On 3/4/07, Marcus Boerger <helly@php.net> wrote:
> Hello Pierre,
>
> Sunday, March 4, 2007, 6:22:03 PM, you wrote:
>
> > To make this long story short, I do not understand the reason behind a
> > glob:// stream wrapper. It makes no sense. But yes, we need a better
> > glob support in PHP. Many extensions needs it. For example, I have my
> > own version for zip, it is bad as the only difference is how I get the
> > path string, the pattern implementation being 100% the same (using
> > pcre or bsd's glob)
>
> So instead of discussing here you should take the glob code of win32
> directory, check the license and either make otwork as you want or reqrite
> it.

I don't get what you are trying to say here.

> Having that stuff in zip makes absolutely no sense at all. Especially
> when it is already there. It is always better to reuse then to provide new
> errors...

Is it not what I just said?

> > You miss/drop my point, I don't like the glob:// wrapper addition. It
> > makes no sense as it has no meaning from a URI point of view.
>
> Then don't use it.

That's a comment I will keep in mind.

> > To have the pattern matching functions (something like fnmatch for
> > example) always available and exported is indeed a good thing. Many
> > extensions can use it. That does not mean we cannot rely on the system
> > versions when available (for the local file operations at least).
>
> >>  Another thing is that doing so would only make
> >> the glob implementation itself profit from this. Providing the other way
> >> makes anything profit from glob support.
>
> > Correct me if I'm wrong but a Iterator+filter can do the same thing
> > without having this ugly glob://
>
> > $iter = new DirectoryIteratorPattern("/dir1/*.jpeg");
> > $iter = new DirectoryIteratorPattern("zip://my.zip/dir1/*.jpeg");
> > $iter = new DirectoryIteratorPattern("ftp://my.zip/dir1/*.jpeg");
>
> It would be much slower. And still glob offers more. It works like your
> system does.

It is certainly not slower and you still did not tell me why a glob://
is required.

> > Given that the stream wrapper provides the minimum set of ops to do it.
>
> What stream wrapper are we talking of now? The pcre filter stream you are
> going to implement?

Ok, a pcre URI wrapper is as insane as this glob://.

> The wrapper that is there right now is glob and yes,
> that one provides the minimum that is needed.

I'm talking about the other wrapper like phar or zip, if they don't
provide all required functions, how will you access the directory
contents? Or know whether a path is a directory or not?

> >> We might even think of adding
> >> support for opening files through glob:// by having it open the first
> >> returned file when used for file opening.
>
> > I suppose we'll need other functions to move the cursor? Or make it
> > move forward magically on each fopen call? That's ugly.  ;-)
>
> Exactly, Hence glob only does what it can do.

Why a new URI then? Please tell why you need a URI.


> > No other language implements blog or fnmatch support in such way but
> > using iterators and filters (in one form or another). Such magic
> > behaviors are always confusing.
>
> No other lanaguage has an Iterator implementation of the power PHP offers.
> So shall we drop that? And guess what languages are different. For example
> no other language has ternary implemented in the way PHP has.

.... take #4

I'm talking about the new *GLOB://* URI not about glob support in
Iterator. One has nothing to do with the other. URI are not PHP
specific, there is some conventions for them. But we tend to ignore
them.

> >> Damn, it apprears we have different taste :-)
>
> > It is not about taste. A glob is not a URI-like data. It is a filter.
> > I hope you understand my point now (for better glob support but no
> > glob://), let see what the other developers think about that.
>
> Just in case you didn't notice. Glob is for directory listing. And the glob
> stream does exactly that in a portable way that can easily be used form
> anything that works on directories. Plain file directories that is because
> glob does not understand anything.

That's why I said it makes sense to have a glob op, a glob URI makes no sense.

>  And should you work on it as described
> above then anything using glob stream will automagically profit from that.
> And this cooperation is the reason we have streams in the first place. If
> you feel i left out zip - which is what your complain sounds like.

It is not about zip, it is not a complain, it is a discussion about
your (wild) addition to the core stream.

To make it clear: I don't like the new glob:// URI. I'm not talking
about iterators goodies or anything else, period.

> Then I
> suppose you go the route I laid down to solve that. It is not of my concern.
> I for one did something that a user brought up, which made perfectly sense
> to me and which already helped me. That is all I need to know.

Before bloating the general wrapper names space with something like
that, you may consider to discuss it on this list before.

Anyway, we are running (again) in circle, you see my comments as
personal attacks and stick to your point, that's bad and that's your
choice.

--Pierre