The :vtable feature has been implemented. Any remaining bugs in the
implementation should be submitted as separate tickets.
Am Mittwoch, 1. November 2006 10:57 schrieb Nicholas Clark:
> When serialising data structures, is parrot going to need to serialise any
> anonymous or otherwise run time generated classes?
Yep, and it does so already.
> If so, isn't this mechanism going to be capable of achieving "compile time"
Am Mittwoch, 1. November 2006 07:43 schrieb Allison Randal:
> We
> may add compile-time construction of classes at some point as an
> optimization, but we'll never eliminate runtime construction.
Of course not. I never said that.
> > To get around that the following came to my mind:
> >
> > - we
On Tue, Oct 31, 2006 at 10:43:11PM -0800, Allison Randal wrote:
> Leopold Toetsch wrote:
> >
> >We have basically the problem that classes are only constructed at
> >runtime, which has 2 negative impacts: associating the vtable info with
> >the class needs some helper storage like the props and n
Leopold Toetsch wrote:
We have basically the problem that classes are only constructed at runtime,
which has 2 negative impacts: associating the vtable info with the class
needs some helper storage like the props and namespaces can only be vaguely
attached to the correct class at runtime too.
Larry Wall wrote:
Indeed, that's part of why Perl 6 eventually threw out properties
entirely, on the supposition that properties are simply attributes
that are mixed in at run-time rather than compiled in.
From an HLL perspective, I agree. But there's always more than one way
to satisfy an HL
On Mon, Oct 30, 2006 at 11:48:14PM -0800, Allison Randal wrote:
: I suspect that originally it was expected that properties would only be
: attached at runtime. But, since we have the option of flagging subs to
: execute at various stages of compilation, it seems safe to assume that
: properties
Am Montag, 30. Oktober 2006 22:53 schrieb Jonathan Worthington:
> Allison Randal wrote:
> > Jonathan Worthington wrote:
> >> I implemented this to test it out and it kinda worked. However,
> >> properties don't get serialized so if you compile the program to a
> >> PBC and run that it doesn't work.
Jonathan Worthington wrote:
This is why properties seemed like a good fit: the vtable entries in
namespaces are optional, out-of-band information, only used in
loading. But, they could just as well be implemented as a separate
attribute in the namespace class.
Agree; looking now at what I had
Jonathan Worthington wrote:
error:imcc:'init' is not a v-table method, but was used with :vtable.
in file 'TGE/Rule.pir' line 49
leo++ fixed half of this when he cleaned up the validation code, but
there was another problem too. Fixed that in 15048, so this should work
now.
This is fi
On Monday 30 October 2006 13:53, Jonathan Worthington wrote:
> Agree; looking now at what I had to do (walk the MRO) to get inheritance
> of :vtable methods to work already, doing it with the data in properties
> is no harder.
This is perhaps a sign that it's time for a super or next opcode.
--
Allison Randal wrote:
Jonathan Worthington wrote:
I implemented this to test it out and it kinda worked. However,
properties don't get serialized so if you compile the program to a
PBC and run that it doesn't work.
Why don't they get serialized?
I guess, that's just not implemented. But I don
Jonathan Worthington wrote:
This is a good place to start, but I agree it's not what we want
ultimately. Chip and I talked about attaching a data structure of
vtable entries as a property on the namespace object.
I implemented this to test it out and it kinda worked. However,
properties don't
chromatic wrote:
On Sunday 29 October 2006 08:25, Jonathan Worthington wrote:
It'd be nice to actually attach these methods to a v-table itself
somehow. However, unless we make classes a compile-time construct rather than
"turning a namespace into a class" using newclass as we do now, I don'
On Sunday 29 October 2006 08:25, Jonathan Worthington wrote:
> It'd be nice to actually attach these methods to a v-table itself
> somehow. However, unless we make classes a compile-time construct rather
> than "turning a namespace into a class" using newclass as we do now, I
> don't see how this
Allison Randal wrote:
Updating Punie went smoothly, but when I updated TGE::Rule:
-.sub __init :method
+.sub 'init' :method :anon :vtable
I got this error:
../../parrot -o TGE/Rule.pbc --output-pbc TGE/Rule.pir
error:imcc:'init' is not a v-table method, but was used with :vtable.
in f
Jonathan Worthington wrote:
Hi,
As of r15039, :vtable and :vtable("...") are now both implemented.
See example code at the end of this email.
Awesome!
As of now, please use this new syntax. I have left in support for the
old "__"-prefix lookup as plenty of old code is using it; please
note
Jonathan Worthington wrote:
Tests and some extra error checking code to come.
Also now done. If you write one of:
.sub not_a_vtable_method :method :vtable
.sub badger :method :vtable("not_a_vtable_method")
It's a compiler error.
I'll leave this ticket open a few more days for comments, then i
Hi,
As of r15039, :vtable and :vtable("...") are now both implemented. See
example code at the end of this email.
As of now, please use this new syntax. I have left in support for the
old "__"-prefix lookup as plenty of old code is using it; please note
that if you have a :vtable("xxx") and
Hi,
Thanks Allison for clarifications and @other for agreement; I've taken
this ticket and will get cracking on implementing this.
Jonathan
On Wed, Oct 25, 2006 at 11:02:59PM -0700, Allison Randal wrote:
> [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
> >>th
[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
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
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40443]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40443 >
At the OSCON 2006 Hackathon, it was decided that we should separate
vtables from met
25 matches
Mail list logo
