On Tue, Feb 09, 2010 at 06:11:13PM +0000, Nicholas Clark wrote:
> On Tue, Feb 09, 2010 at 05:46:23PM +0000, Tim Bunce wrote:
> > On Tue, Feb 09, 2010 at 03:33:53PM +0000, Nicholas Clark wrote:
> > >
> > > I'm just not yet sure about the C source file names. I assume that the
> > > file
> > > handle XS stays in Devel::NYTProf::FileHandle, so it's a name for the
> > > low(er)
> > > level IO code, such as output_int() and friends.
> >
> > Seems reasonable. Though perhaps FileHandle should disappear and the
> > guts of it become private to the new higher-level interface.
> > Trying to keep FileHandle around may give more pain for little gain.
>
> There seem to be several parts. And I'm not sure how to name them
>
> 1: The C functions in FileHandle.xs, prefixed NYTP_, which deal with the low
> level operations of moving data in and out of files
> 2: The building blocks immediately on top of them (output_{int,nv,str})
> currently in NYTProf.xs
> 3: The higher level abstractions (that don't yet exist) - a subroutine per
> tag type that we need to output
> 4: Potentially a C callback based input parser
> (With NYTProf.xs refactored to supply callbacks to read the data)
>
> There would need to be XS wrappers to (at least) the open and close functions
> in (1), and everything in (3).
Yes, though 3 should probably encapsulate the open and close functions in 1.
So 1 would then be completely hidden.
> (2) is what nytprofmerge currently uses. In theory we could abolish
> wrappers of (2), *but* it would be useful to keep them to facilitate
> prototyping and doing things outside the current applications.
Umm, seems like YAGNI to me at the moment. Got a use-case?
> So in theory all of the above C functions could be in one file.
> Or in two. (1) vs (2,3,4)
> Or in two. (1,2) vs (3,4)
>
> I'm not sure which.
I'd be happy with one for the C code, generating an nytprofio library,
and one, or more, for the read/write XS interface(s) to that library.
> And I'm not sure whether the XS wrappers go in the same file, or a different
> file. And 1 namespace or several.
I can see strategic value in having XS wrappers in a separate file.
In that keeping the C code separate and free from perl-isms would move
us closer to being able to generate data for NYTProf from other sources.
> Or what names anything has. Particularly as "profile" could mean the abstract
> concept of a profile, or routines to manipulate a file on disk in our format.
> [ie (2,3,4) above]
'nytprofio' seems like a reasonable name for the C code implementing the I/O.
Tim.
--
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]
