[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
TSa wrote:
I want to summarize what we have so far.
1) In type constraint position we can say things like A|B to effectively
mean a supertype of A and B by virtue of $_ ~~ A || $_ ~~ B.
Right. This would be equivalent to "Any where {.does(A) or .does(B)}".
2) We have A&B and the A B jux
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
HaloO,
Trey Harris wrote:
In other words, I agree that it's fuzzy, but I personally read the
fuziness as intentional, so as to allow implementations flexibility and
prevent bad dependencies on particular "inner workings" of the type system.
Thanks for the support. I figured that I've asked th
Bob,
Many thanks for your reply! That's exactly the subtlety I was
interested in knowing.
Regards,
Paul
In a message dated Wed, 25 Oct 2006, TSa writes:
from the recent threads 'class interface of roles', 'set operations for
roles' and 'signature subtyping and role merging' I wonder how typish
roles actually are. Some seem to consider roles as lightweight particles
that serve to compose classes.
HaloO,
from the recent threads 'class interface of roles',
'set operations for roles' and 'signature subtyping
and role merging' I wonder how typish roles actually
are. Some seem to consider roles as lightweight
particles that serve to compose classes. I see them
as the heavyweights in the type d
17 matches
Mail list logo
