> From: Tom Christiansen <tchrist@mox.perl.com>
>
> >As I've said elsewhere I believe that SFIO will work 'under the hood' of
> >stdio and with a narrow scope (read/write/seek/exceptions).
>
> >I believe both OO (for user level code) and SFIO (for some whizz-bangs)
> >are important and complementrary. They can be separate, with no clash.
>
> Hm... if sticking in SFIO is a massive project, isn't htere at
> least a free portable stdio implementation bundled in with something
> like Cnews (I forget where it was) that we might use?
The sticky issues surrounding SFIO are issues which would apply to any
stdio replacement. Mainly binary compatibility with libraries which
have been linked with the default stdio.
The SFIO implementation seems to have addressed these issues in depth
(and probably better than other stdio replacements). This makes it all
the more attractive for Perl since Perl has very exacting requirements
(dynamically loading extensions linked to third-party archive libraries).
SFIO is only 'a massive project' if you try to design an interface to
disciplines and other whizz-bangs features on day one. The downside of
an SFIO module is that it becomes very tempting to do it all.
I think we'd be better of concentrating on getting the stdio compatible
core SFIO functionality integrated first and then think about expanding it.
(Just an sfio subdirectory with a Makefile.SH and hooks into config.sh
would be a great start.)
Perl needs SFIO even _without_ disciplines.
Tim.
>
> >As I've said elsewhere I believe that SFIO will work 'under the hood' of
> >stdio and with a narrow scope (read/write/seek/exceptions).
>
> >I believe both OO (for user level code) and SFIO (for some whizz-bangs)
> >are important and complementrary. They can be separate, with no clash.
>
> Hm... if sticking in SFIO is a massive project, isn't htere at
> least a free portable stdio implementation bundled in with something
> like Cnews (I forget where it was) that we might use?
The sticky issues surrounding SFIO are issues which would apply to any
stdio replacement. Mainly binary compatibility with libraries which
have been linked with the default stdio.
The SFIO implementation seems to have addressed these issues in depth
(and probably better than other stdio replacements). This makes it all
the more attractive for Perl since Perl has very exacting requirements
(dynamically loading extensions linked to third-party archive libraries).
SFIO is only 'a massive project' if you try to design an interface to
disciplines and other whizz-bangs features on day one. The downside of
an SFIO module is that it becomes very tempting to do it all.
I think we'd be better of concentrating on getting the stdio compatible
core SFIO functionality integrated first and then think about expanding it.
(Just an sfio subdirectory with a Makefile.SH and hooks into config.sh
would be a great start.)
Perl needs SFIO even _without_ disciplines.
Tim.