Eryq wrote [seriously elided by jdp]:
>
> they would be even more informative if, instead of
> using =head2 or =item to document our APIs, we had things
> like this:
> =method open FILENAME
> =method
> @type class,instance
>
> That's why I favor taking generally-useful things
John Porter wrote:
> > For more flexibility, the test could look at an inline_tests.t.list
> > file in the cwd to determine *which* .pm's should be tested.
>
> This could be done now, without further ado.
>
> ##
> # testing code here...
> ...
> ##
>
> Podulation
> Imagine a special "inline_tests.t" which goes through every
> .pm in the distribution's "lib" directory, and runs every
> in-line test it finds directly (WITHOUT extracting it to a .t).
> All we'd need is one; it would be general-purpose, and you
> could just download it from CPAN and stick it
John Porter wrote:
>
> Glenn Linderman wrote:
> >
> > 1) why extract it if it could potentially be used in place
> > 2) if it cannot be used in place, then why bundle it
>
> I tend to agree. If they're stored as podified sections, and
> get extracted to files, then pod has merely been (mis-)use
Glenn Linderman wrote:
>
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
I tend to agree. If they're stored as podified sections, and
get extracted to files, then pod has merely been (mis-)used as
some kind of shar.
If the t
On Thu, Sep 14, 2000 at 12:15:28PM -0700, Glenn Linderman wrote:
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
>
> So I guess RFC 183 leaves me not understanding its goals. If there
> is a benefit to the bundling, then RFC 183
Michael,
Thanks for the explanation. So you see, I'm one of those people that go around
looking for redundancies to eliminate. So when I hear that you want to extract
a .t file from perl source (as specified by the RFC 183), it makes me wonder
1) why extract it if it could potentially be used
Eryq wrote:
>
> I'm weary of proposals like "lets add/extend named operator X".
> Perl needs *fewer* special cases, not *more*. I want the
> following pairs to ALWAYS be identical, and ALWAYS mean
> method invocation:
>
> open THING ARG,...,ARG
> THING->open(ARG,...,ARG)
>
>
Nathan Wiger wrote:
> I think this is a definite possibility:
>
>$FH = open scalar $myvar;
>print $FH "stuff";
>
> Then the scalar handler would just have to provide the necessary print()
> et al methods to do scalar manipulation. Theoretically this can be done
> modularly, without havi
Glenn Linderman wrote:
>
> I have a number of scripts that use this sort of facility, using push/shift
> to populate/read the array "file". These could be made simpler and more
> general by wrapping the array as a file.
>
> Perhaps the open "handler" stuff could be used to implement this?
> Eff
On Thu, Sep 14, 2000 at 12:01:03AM -0700, Glenn Linderman wrote:
> > Once extracted, a module can deal with it
> > just as easily, and with much more flexibility, than a core patch to
> > perl can.
>
> Who cleans up all the junk files later?
Nobody does, they're not junk. They go into the t/ di
Michael G Schwern wrote:
> On Wed, Sep 13, 2000 at 11:21:25PM -0700, Glenn Linderman wrote:
> (3)
> > obtain one or more data handles for test input data and validation data, (4)
> > compile 1&2 as perl source code, and (5) launch the tests, which can then
> > used the appropriate data handles.
>
On Wed, Sep 13, 2000 at 11:21:25PM -0700, Glenn Linderman wrote:
> This RFC also seems to be related to RFC 183... using POD for testing. Now
> the model of use apparently envisioned for RFC 183 is to have the tests
> inside the POD, and then use a preprocessor to hack them out and put them in
>
13 matches
Mail list logo
