On Thu, Feb 11, 2010 at 05:07:22PM +0000, Nicholas Clark wrote: > On Thu, Feb 11, 2010 at 04:53:37PM +0000, Tim Bunce wrote: > > On Thu, Feb 11, 2010 at 01:35:25PM +0000, Nicholas Clark wrote:
> > > Removing perl-isms would require rewriting read_str(), as it returns an > > > SV. > > > That's not a problem - it just means thinking about what's the best way to > > > represent a string that may (or may not) be UTF-8 encoded. > > > > I don't see as much value in avoiding perl-isms on the reading side. > > Though I guess allowing perl-isms on the reading side implies having > > separate libraries for writing and reading, which probably isn't > > worthwhile. > > Yes, that's the bind. Also, looking again FileHandle.xs, there are already some perl-isms entangled there, in the error reporting [croak()] There might be a good way to untangle that whilst retaining the level of detail it can provide, but if so, it's not immediately obvious. Also, I removed one trace > 10 bit of logging from (IIRC) output_str() when moving it to FileHandle.xs, as otherwise it would produce further entanglement between the two files. Right now, all the logging has static linkage and is not exposed from NYTProf.xs. I didn't hugely want to change that. There are more croak()s in the reading functions, and more tracing. It feels like it would be progress to first split the functions out, retaining the perl-isms (not sure about the logging), because that would 1: at least decouple the XS-space users from the Perl-space users 2: make it a lot clearer what the remaining perl-isms are. Nicholas Clark -- You've received this message because you are subscribed to the Devel::NYTProf Development User group. Group hosted at: http://groups.google.com/group/develnytprof-dev Project hosted at: http://perl-devel-nytprof.googlecode.com CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf To post, email: [email protected] To unsubscribe, email: [email protected]
