Hi all,
The attached patch to the coding standards pdd concerns how we handle
the parrot emacs/vim coda in perl source files when the files contain
__END__ or __DATA__ blocks. The reason for the patch is that vim looks
at only the first or last five lines of a file to see if there is any
styl
Patrick R. Michaud wrote:
We might want to resurrect the 'compile' opcode as an indirect syntax
for making the 'compile' method call.
Maybe, but I can't see that this is worthy of a special opcode
(and presumably a vtable slot?). There's just not a lot of
difference between:
$P0 = compi
Am Mittwoch, 15. November 2006 05:52 schrieb Allison Randal:
> We might want to resurrect the 'compile' opcode as an indirect syntax
> for making the 'compile' method call.
Please don't. Opcodes are very limited re calling conventions. Mehthods are by
far more flexible when it comes to pass argum
Leopold Toetsch wrote:
Please don't. Opcodes are very limited re calling conventions. Mehthods are by
far more flexible when it comes to pass arguments to compilers.
I believe we've been through this conversation before. I don't mean
coding a completely different opcode, I just mean using th
Hi @all,
[ shortened: ]
Recommendation: Deprecate property support in PMCs.
Allison: Would it help if we call them "static attributes" and "dynamic
attributes"?
No. Attributes and properties are almost orthogonal concepts.
Properties are per PMC (or object, as that's a PMC too)
Am Mittwoch, 15. November 2006 22:38 schrieb Allison Randal:
> Leopold Toetsch wrote:
> > Please don't. Opcodes are very limited re calling conventions. Mehthods
> > are by far more flexible when it comes to pass arguments to compilers.
>
> I believe we've been through this conversation before. I d
Leopold Toetsch wrote:
>
> Properties are never inherited, they belong to just that one PMC.
Well, yeah. That's what they're designed to do. But agreed that for the
sake of clarity attributes and properties should keep two separate names.
> Therefore a
> much more efficient implementation of c
chromatic wrote:
Properties:
I don't remember what problem these try to solve. It's difficult to discuss
one way or the other without an example.
They're solving the problem of allowing attribute-like information to be
attached to an object at runtime. In Perl 5, objects are blessed hashes
On Wednesday 15 November 2006 17:04, Allison Randal wrote:
> Will this not be alleviated by the new variable-sized PMCs you're
> prototyping? Anyway, I can't see that allocating storage for a single
> reference to another data structure is going to break the bank.
Seems like you'd always pay for
Leopold Toetsch wrote:
And, I do think making the PASM and PIR compilers capable of being used
as standard compiler objects is a superior solution.
We currently can't pass any arguments to PASM/PIR compilers. You can't change
trace or debug options for "eval". This is a serious limitation, w
10 matches
Mail list logo
