[EMAIL PROTECTED] via RT wrote:
On Sun Oct 01 16:22:10 2006, mdiep wrote:
At the OSCON 2006 Hackathon, it was decided that we should separate
vtables from methods and add a new :vtable label for PIR subs to mark
them as vtable functions. This gets rid of the current namespace
pollution caus
Jonathan Worthington wrote:
OK, so I've added a REQUIREMENTS section to the objects PDD now and
filled it out with some (hopefully most) of what Perl 6 and .Net need as
a start.
Thanks Jonathan, it's a great start!
Allison
On Wednesday 25 October 2006 16:38, [EMAIL PROTECTED] via RT wrote:
> Just to check, that this is still meant to happen?
Unless Allison objects, it seems like the cleanest way to support overloading
semantics from various languages (Perl 5: FETCH, Python:
__some_really_ugly_method_name__) witho
On Sun Oct 01 16:22:10 2006, mdiep wrote:
> At the OSCON 2006 Hackathon, it was decided that we should separate
> vtables from methods and add a new :vtable label for PIR subs to mark
> them as vtable functions. This gets rid of the current namespace
> pollution caused by vtables and allows u
Allison Randal wrote:
More specifically: If you have any questions related to a PDD in clip,
please add them to a QUESTIONS section at the end of the PDD. For
requirements, use REQUIREMENTS. Neither of these sections will live in
the final version of the PDD, so it's a flag for me to process th
Author: jonathan
Date: Wed Oct 25 15:29:31 2006
New Revision: 15024
Modified:
trunk/docs/pdds/clip/pdd15_objects.pod
Log:
Add REQUIREMENTS section to PDD15 Objects, to enable us to start fleshing out
what Parrot's object system needs to do. Includes hopefully most of what Perl 6
and .Net nee
Adding the file to the INTERP_O_FILES section in
config/gen/makefiles/root.in and re-running Configure should do the trick.
--AT
On 10/24/06, Karl Forner <[EMAIL PROTECTED]> wrote:
On 10/23/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
>
> Karl Forner wrote:
> > I've added one C src file
On Oct 25, 2006, at 3:23 PM, jerry gay wrote:
one overall test for perlcritic is fine with me. there's nothing
stopping us from parsing perlcritic output if we want a different
format, however i'd rather not go that far.
additionally, i'd like to see less verbose output from perlcritic. the
tho
On 10/25/06, Chris Dolan <[EMAIL PROTECTED]> wrote:
On Oct 25, 2006, at 1:24 PM, Jerry Gay (via RT) wrote:
> modify perl coding standard test format to match the c tests--one test
> per standard, rather than one test per file.
>
> coding standard tests are designed to test maintainability, not
>
On Oct 25, 2006, at 1:24 PM, Jerry Gay (via RT) wrote:
modify perl coding standard test format to match the c tests--one test
per standard, rather than one test per file.
coding standard tests are designed to test maintainability, not
functionality. testing parrot functionality is much more imp
On 10/24/06, Will Coleda <[EMAIL PROTECTED]> wrote:
Not all tests follow the "one test reporting on many files" paradigm:
see t/codingstd/perlcritic.t
FWIW,in general, I prefer the perlcritic method.
as i just wrote in a new ticket for perl coding standard test reformatting...
coding standard
# New Ticket Created by Jerry Gay
# Please include the string: [perl #40596]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40596 >
modify perl coding standard test format to match the c tests--one test
per standard, rather
Bob,
Many thanks for your reply! That's exactly the subtlety I was
interested in knowing.
Regards,
Paul
13 matches
Mail list logo
