On 23 November 2014 18:39:18 GMT, Bill Salak <b...@devtemple.com> wrote: >Hi list, > > > >I'm considering writing an RFC to add a 3rd parameter to fgets which >accepts >a user defined function. If we had this today we wouldn't need fgetcsv >with >the added benefit of fgetcsv style support for data packaging formats >we >would otherwise create more 1 off functions for. For example, if we >decided >to support reading json from files in the same manner as our current >fgetcsv >functionality today, we would create an fgetjson function. > > > >This change unifies the way in which we support native transliteration >of >data packaging formats from files into php data structures through a >single >interface. The other major design benefit, from my point of view, is >the >unification of userland transliteration functions/libraries with the >same >modality as our native support for these types of use cases. I believe >this >will ultimately result in more intuitive userland code around this type >of >functionality.
It's an interesting idea, but I can't immediately picture how it would work - what would the callback be given, and what would it return? Would it somehow be able to manipulate the number of characters read from the stream? For any variant of CSV, reading a line at a time is what you want anyway, and you can easily build an Iterator which post-processes each line as it is read, giving the memory efficiency of fgetcsv() but much more flexibility. For JSON, newlines aren't the delimiter you want, but with nested structures, I'm not sure how you'd parse a partial structure anyway. Are there JSON equivalents of SAX (event-based) parsers? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
