Re: Making stream functions accepting SplFileObject as valid parameter
| From: | ignace nyamagana butera | Date: | Thu, 05 Oct 2017 10:42:59 +0000 |
| Subject: | Re: Making stream functions accepting SplFileObject as valid parameter | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-100824@lists.php.net to get a copy of this message | ||
Does adding new methods to SplFileObject easier ? It would mean adding a
getMetaData() (to return stream_get_meta_data infos) method and
(append/prepend/remove)Filter methods to add stream filters API.
On Tue, Oct 3, 2017 at 5:21 PM, Sara Golemon <pollita@php.net> wrote:
> On Tue, Oct 3, 2017 at 9:44 AM, Dan Ackroyd <danack@basereality.com>
> wrote:
> > On 29 September 2017 at 07:46, nyamsprod the funky webmaster
> > <nyamsprod@gmail.com> wrote:
> >>
> >> I've been following the resolution of this bug:
> >>
> >> https://bugs.php.net/bug.php?id=44392
> >>
> >> and it seems that there is no safe way to expose the internal
> >>
SplFileObject filepointer.
> >
> >
> > It seems that people are scared to comment on a streams related
> question...
> >
> Nah, just distr... OOH SHINY!
>
> > I'm not sure that making stream_* functions accept SplFileObject's
> > would be an appropriate way to solve this problem; it's just too much
> > of a hack.
> >
> Implementation wise, about as difficult as you'd imagine. We have
> php_stream_from_zval() which is a central place which could be made
> smarter, though most (all?) stream related functions have IS_RESOURCE
> checks that'd have to be dealt with, so it still means touching the
> world.
>
> > However, although it's not safe to expose the underlying file handle
> > used by SplFileObject, I think it _might_ be safe to allow the
> > SplFileObject to return a stream that represents the file, but with
> > the necessary php_stream_ops that aren't safe to use replaced with NOP
> > operations, similar to how it is done in the pgsql extension:
> >
> > https://github.com/php/php-src/blob/879126a2cedef5b6e1c1f701ade17c
> a3da9a39ec/ext/pgsql/pgsql.c#L5406-L5409
> >
> I like this approach in the abstract (though I haven't paged in the
> entire problem space yet). A proxy wrapper provides (possibily
> implemeted on the SplFileObject itself) keeps the scope of the change
> localized to SPL and has little residual hack smell.
>
> -Sara
>