Simon Cozens <[EMAIL PROTECTED]> writes:
> Arthur Bergman:
>> I am wondering how the references to hash elements are planned to be
>> done? The call to set_ must somehow be delayed until the time is right.
>
> I would have thought that a hash element would itsel
Paul Johnson <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch said:
>>
>> IMHO we are additionally lacking vtable methods to achieve the HLL value
>> assign behavior: We only have references inside our aggregates. That
>> doesn't matter per se, you can always clone the PMCs before storing, or
>> you s
Leopold Toetsch said:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
>> This is entirely a matter of opinion and data design ...
>
> Yep, that's it. The current behavior additionally is inconsistent.
> Retrieving a reference (that is Parrot) out of a non-existant hash key
> gives and unrelated new Pe
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This is entirely a matter of opinion and data design ...
Yep, that's it. The current behavior additionally is inconsistent.
Retrieving a reference (that is Parrot) out of a non-existant hash key
gives and unrelated new PerlUndef, when assigning to that, n
At 1:32 PM -0800 1/6/04, Jeff Clites wrote:
On Jan 6, 2004, at 9:25 AM, Leopold Toetsch wrote:
Arthur Bergman <[EMAIL PROTECTED]> wrote:
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is right.
$foo =
Arthur Bergman <[EMAIL PROTECTED]> wrote:
> Hi,
> I am wondering how the references to hash elements are planned to be
> done? The call to set_ must somehow be delayed until the time is right.
Here is a pointer to the last discussion on that topic:
Date: Thu, 21 Aug 2003
On Jan 6, 2004, at 1:31 PM, Simon Cozens wrote:
Jeff Clites:
But here what I'm copying is the _contents_ of the hash slot.
True, but irrelevant. :)
And here I'm not making a copy, but also the thing I'm taking a
reference to is not the same thing I copied above. Here, it's a
reference to a hash s
On Jan 6, 2004, at 9:25 AM, Leopold Toetsch wrote:
Arthur Bergman <[EMAIL PROTECTED]> wrote:
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is
right.
$foo = \$hash{key};
$$foo = "bar";
Jeff Clites:
> But here what I'm copying is the _contents_ of the hash slot.
True, but irrelevant. :)
> And here I'm not making a copy, but also the thing I'm taking a
> reference to is not the same thing I copied above. Here, it's a
> reference to a hash slot.
No, it isn't. It's a reference t
[ apologies for the duplicate email message from my last post--mail
client problems... ]
On Jan 6, 2004, at 11:50 AM, Simon Cozens wrote:
Jeff Clites:
$a = $hash{bar};
Here you used the copy constructor before taking the reference. It
might look
like an assignment operator, but it isn't. You're
At 4:53 PM + 1/6/04, Arthur Bergman wrote:
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is
right.
Nope, actually they don't have to be. Simon was correct here.
Accessing an element of an aggr
Arthur Bergman writes:
>
> On 6 Jan 2004, at 17:05, Simon Cozens wrote:
>
> >
> >I would have thought that a hash element would itself be a PMC rather
> >than an immediate value, so a reference to that should be treated just
> >like any other reference to a PMC.
> >
>
> But this does not hold tru
On 6 Jan 2004, at 17:05, Simon Cozens wrote:
I would have thought that a hash element would itself be a PMC rather
than an immediate value, so a reference to that should be treated just
like any other reference to a PMC.
But this does not hold true if the hash element is in fact conjured up
by
Simon Cozens writes:
> > $a = $hash{bar};
>
> Here you used the copy constructor before taking the reference. It might look
> like an assignment operator, but it isn't. You're better off thinking that
> assignment doesn't exist. It's a copy constructor. It makes the PMC referred
> to by $a a copy
Jeff Clites:
> But there's a semantic difference between a "reference to a hash
> element" and a "reference to something which happens to have come out
> of a hash".
True, but irrelevant. :)
> $a = $hash{bar};
Here you used the copy constructor before taking the reference. It might look
like a
On Jan 6, 2004, at 9:05 AM, Simon Cozens wrote:
Arthur Bergman:
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is
right.
I would have thought that a hash element would itself be a PMC rather
than an immediate
Arthur Bergman <[EMAIL PROTECTED]> wrote:
> Hi,
> I am wondering how the references to hash elements are planned to be
> done? The call to set_ must somehow be delayed until the time is right.
> $foo = \$hash{key};
> $$foo = "bar";
> $has{key} is now "b
Arthur Bergman:
> I am wondering how the references to hash elements are planned to be
> done? The call to set_ must somehow be delayed until the time is right.
I would have thought that a hash element would itself be a PMC rather
than an immediate value, so a reference to that should be t
Hi,
I am wondering how the references to hash elements are planned to be
done? The call to set_ must somehow be delayed until the time is right.
$foo = \$hash{key};
$$foo = "bar";
$has{key} is now "bar"
I don't see how the current vtable setup will allow for this
19 matches
Mail list logo
