On Tue, May 31, 2005 at 07:10:42PM -0700, TOGoS wrote:
> Why not extend this to properties, too?
I don't know of a good use case for that.
Now multidimensional arrays are common enough, and workarounds to
emulate them are enough of a pain[*], that Parrot support for them
makes sense. In contrast
At 7:10 PM -0700 5/31/05, TOGoS wrote:
> The 'used as' type indicates whether this key
is to be used to do a by-integer-index (array)
access or by-string-index (hash) access.
Why not extend this to properties, too?
Because properties (and attributes) are metadata. At the moment
properti
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> TOGoS <[EMAIL PROTECTED]> wrote:
>
> > --- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> >> TOGoS wrote:
> >>
> >> > Why not extend this to properties, too?
> >>
> >> > foo.hello becomes
> >> >
> >> > 'hello'
> >> > string
> >> > as
TOGoS <[EMAIL PROTECTED]> wrote:
[ anwser rearranged for readability ]
> --- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> TOGoS wrote:
>>
>> > Why not extend this to properties, too?
>>
>> > foo.hello becomes
>> >
>> > 'hello'
>> > string
>> > as-property
>>
>> Because that's a
perl6-internals: the place to go to have people tell
you things you already know and not actually answer
your question at all.
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> TOGoS wrote:
>
> > Why not extend this to properties, too?
>
> > foo.hello becomes
> >
> > 'hello'
> > stri
TOGoS wrote:
Why not extend this to properties, too?
foo.hello becomes
'hello'
string
as-property
Because that's an attribute access:
$P0 = getattribute foo, "hello"
leo
> The 'used as' type indicates whether this key
> is to be used to do a by-integer-index (array)
> access or by-string-index (hash) access.
Why not extend this to properties, too?
foo['hello'] becomes
'hello'
string
as-offset
foo{'hello'} becomes
'hello'
string
I've added this PDD to CVS after taking note of Dan's comments.
--
And it should be the law: If you use the word `paradigm' without knowing
what the dictionary says it means, you go to jail. No exceptions.
-- David Jones
At 7:19 PM + 2/19/02, Nicholas Clark wrote:
>On Mon, Feb 18, 2002 at 01:12:24PM -0500, Dan Sugalski wrote:
> > Non-aggregates can (and must) implement the _keyed vtable method,
> > though it may well do nothing but throw an exception.
> >
> > References, for example, will implement them, j
On Sun, Feb 17, 2002 at 05:51:32PM +, Simon Cozens wrote:
> =head2 Aggregate and non-aggregate PMCs
>
> We've already said that what separates the aggregate PMCs from the
> non-aggregates is their implementation of the C<_keyed> vtable methods.
> So it is Hereby Decreed that the default vtab
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Need discussion on whether C is a good exception for
> this, or whether something else should be used. It's really a compiler
> screw-up, since code which indexes a non-aggregate shouldn't be
> generated.
Except of course references, where the compiler ca
Brian Lee Ray:
> I'm not a perl programmer , I'm a C programmer,
Ooh good, we could do with a few more of those around... ;)
> >Need discussion on whether C is a good exception for
> >this, or whether something else should be used. It's really a compiler
> >screw-up, since code which indexes a n
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> This is a singularly bad name, and needs to change. Probably
>> C is better. It's a shame C is so confusing,
>> since it's accurate.
DS> AGGREGATE_INDEX is good, but awfully big.
what about plain INDEX? or AGG_INDEX if you must.
Thanks for this one. Few things:
At 5:51 PM + 2/17/02, Simon Cozens wrote:
>=head1 DESCRIPTION
>
>First, let's define some terminology. An B is one which
>supports and implements the C<_keyed> variants of vtable methods. These
>variants are B operations, as they act on a specific indexed
>ele
14 matches
Mail list logo
