Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Togos <[EMAIL PROTECTED]> wrote:
>> Should aggregate PMCs (like PerlHash) be able to take
>> PMCs as keys? I mean so that:
>
>> $P0 = $P1[$P2]
>
> Just use a Key PMC for $P2.
>
> $P2 = new Key
> $P2 = "key_string"
> ...
So, just for fun I adde
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>
>> Then, at runtime, 'fred' gets set up as the implemntation for an op.
>
>> Which, given your implementation, means that each function call that
>> fred makes should be protected with savetop/restoretop pairs.
Cross-posted to module-build-general, p5p and perl-qa. Please trim CCs
if your reply isn't relevant to all the lists. I'm not subscribed to
module-build-general.
On Wed, Jun 02, 2004 at 12:09:01AM -0500, Ken Williams wrote:
> I've just released a new beta of Module::Build to CPAN. This is a
>
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 <[EMAIL PROTECTED]> wrote:
> At 9:51 AM +0200 6/2/04, Leopold Toetsch wrote:
>>- don't load extensions at compile time, so that dynamic PMCs have to be
>> created with
>>
>>$I0 = find_type "Foo"
>>$P0 = new $I0
> Option two here would be the right one.
For dynamic PMC class
Bernhard Schmalhofer (via RT) wrote:
following the lead of TCL, I have adapted the Parrot m4 test scripts
to the new unified testing scheme.
Applied, thanks
leo
