At 3:01 PM -0400 6/4/04, Matt Fowles wrote:
All~
Perhaps I am missing something in this discussion, but wouldn't it
be possible to have the vtable within a PMC be layered rather than
the PMC itself.
There are two problems with that (though I did think about it for a while):
1) It means that each
> At 12:54 AM -0400 6/3/04, Benjamin K. Stuhl wrote:
>>(with one major caveat: if the _vtable_ functions try to use the
>>PMC's address as an index into some data structure, things will go
>>wrong since the PMC the base vtable functions get no longer has the
>>same address as the logical PMC; if ex
> All~
>
> Perhaps I am missing something in this discussion, but wouldn't it be
> possible to have the vtable within a PMC be layered rather than the PMC
> itself. This would allow the data portion of PMC's to remain in a fixed
> location, while allowing new vtable layers to be pushed/popped.
All~
Perhaps I am missing something in this discussion, but wouldn't it be
possible to have the vtable within a PMC be layered rather than the PMC
itself. This would allow the data portion of PMC's to remain in a fixed
location, while allowing new vtable layers to be pushed/popped.
At 12:54 AM -0400 6/3/04, Benjamin K. Stuhl wrote:
(with one major caveat: if the _vtable_ functions try to use the
PMC's address as an index into some data structure, things will go
wrong since the PMC the base vtable functions get no longer has the
same address as the logical PMC; if external
I sent this message out a few days ago, but never saw it show up on the
list... Just to recap
a) option #1 seemed best to me
b) this will all happen at the parrot level
c) languages will almost never "change" an object to read-only
d) there are some reasons that old access to an object should
Dan Sugalski wrote:
At 11:55 AM +0200 5/30/04, Leopold Toetsch wrote:
What about the current implementation [1]:
Leo, you're missing the point pretty badly here
I don't think so. I've described a static scheme in terms of read-only PMCs.
1) static read-only layering
Needs one extra vtable per PMC.
Dan Sugalski wrote:
Okay, time to think about this.
We need the ability to layer PMCs. Nothing new, we need something of the
sort for transparent read-only-ness and probably thread-safety (though
we don't have to do it that way) and folks are going to want to do
undoable custom vtable layering.
On Sat, 2004-05-29 at 15:29, Dan Sugalski wrote:
> The problem with the first scheme is that anything that has a handle
> on the PMC will not get the new layers. Not a good thing.
I like the first scheme. The question that comes up is: when does
something get layered?
That is: if I have code th
On Mon, 2004-05-31 at 21:26, Brent 'Dax' Royal-Gordon wrote:
> Can this be done with special subclasses? Sure. But if we do it with a
> true layering system, we get an incredible amount of power essentially
> for free.
That sounds suspiciously like Perl 6 roles.
-- c
Leopold Toetsch wrote:
Combinatorial explosion. This already requires four variants (normal,
const, threadsafe, const threadsafe), and we haven't even seen what real
users will want to do with PMCs yet.
Not quite. A const PMC is already thread-safe.
Hmm, good point. (I guess you can't set propert
At 11:55 AM +0200 5/30/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
We need the ability to layer PMCs. Nothing new, we need something of
the sort for transparent read-only-ness and probably thread-safety
What about the current implementation [1]:
Leo, you're missing the poin
At 10:23 PM +0200 5/29/04, Stéphane Payrard wrote:
You are considering read-ony PMC versus others. Another issue
is properties. Many PMCs "classes" will support properties that will
alter their behavior. But most PMC instances will have no property
attached to them. Or just default values of them
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>>We need the ability to layer PMCs. Nothing new, we need something of
>>>the sort for transparent read-only-ness and probably thread-safety
>>
>> What about the current implemen
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
We need the ability to layer PMCs. Nothing new, we need something of
the sort for transparent read-only-ness and probably thread-safety
What about the current implementation [1]:
* PMCs that have read-only variants have the C flag set
*
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We need the ability to layer PMCs. Nothing new, we need something of
> the sort for transparent read-only-ness and probably thread-safety
What about the current implementation [1]:
* PMCs that have read-only variants have the C flag set
* the PMC compiler
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> To avoid to go back the slow world of perl5 where many things
> need to be tested before figuring what to do, performancewise,
> there is little choice but to have two versions of each PMC
> class, a fast one that is devoid of property support and anoth
Dan Sugalski wrote:
We need the ability to layer PMCs. Nothing new, we need something of the
sort for transparent read-only-ness and probably thread-safety (though
we don't have to do it that way) and folks are going to want to do
undoable custom vtable layering. While we don't *have* to let 'em
You are considering read-ony PMC versus others. Another issue
is properties. Many PMCs "classes" will support properties that will
alter their behavior. But most PMC instances will have no property
attached to them. Or just default values of them if you see it that
way.
To avoid to go back the sl
19 matches
Mail list logo
