Re: file streams & metadata

From: Date: Tue, 08 Mar 2011 16:08:33 +0000
Subject: Re: file streams & metadata
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18  Groups: php.internals 
Request: Send a blank email to internals+get-51622@lists.php.net to get a copy of this message
On Tue, Mar 8, 2011 at 1:55 PM, Pierre Joye <pierre.php@gmail.com> wrote: > On Mon, Mar 7, 2011 at 10:49 PM, Ferenc Kovacs <info@tyrael.hu> wrote: > > > From the sideline: > > it's hard to belive that there are no one else with opinion on this > matter. > > I don't want to take sides because I don't have the necessary knowledge > > about the matter, but maybe it would be a good idea to write an RFC, and > and > > maybe a POC, so we can see how intrusive would be the implementation. > > and if there are more bystanders, then please make your voice heard. > > Tyrael > > It is very easy to implement what Stas is asking. But that's not the > question. The question is should we do it? And my point is that we > should not do it like that, bad design, incomplete and limited > support. > > if you have a better alternative which is viable, then I would support that. otherwise I wouldn't support the all-or-nothing approach. thats like if we couldn't add pecl/phpize until it works on every supported platform/filesystem combination. (cheers for the upcoming 5.3.6 release) and there is a ton of stuff which some point in time (or still ) didn't work on all platform. I think the best thing would be extending streams for every possible method/operation, but require the userland developer to register callbacks for the requested operation, and this way vfsStream devs could mock the chmod calls but the built-in wrappers still would behave correctly (if they didn't explicitly implement/support that operation, they would throw an warning just like now) it's not a generic implementation, but we could allow every single method to be mockable, and we could gradually add support for the new operations for the built-in wrappers. maybe there are other reasons/use-cases for which this solution is not good enough, but it would solve the the initial problem. ps: sorry if I'm missing something, please feel free to point that out. Tyrael

« previous php.internals (#51622) next »