Dan Sugalski wrote:
>
> At 04:39 PM 10/1/00 -0700, Peter Scott wrote:
> > What are the chances of the internals supporting user-defined
> >attributes? What would the API look like?
>
> Well, yeah, it'll sort of have to if we allow user-defined types. If you do:
>
>my Dog $spot : male;
>
>
Peter Scott wrote:
>
> Maybe I'm just being dense, but why shouldn't arrays and hashes inherit
> attributes from UNIVERSAL?
I think, rather, they should inherit from some other root class,
since UNIVERSAL is for blessed things.
> Hmm, am I saying that I should be able to
> write @array->met
Nathan Wiger wrote:
> I pushed a lot of these issues in RFC 319 and 337, which would let you
> say something like:
>
>my Pet @pets :mean; # integrated implicit tie
>@pets->attributes('mean') # "true", like 'can'
Blech.
exists @pets:mean # true
--
John Porter
> I may be raining on your RFC 337 parade here (sorry I didn't get to it
> earlier - travel), but I think it entirely reasonable to want to specify a
> type for an array different from the type of thing it contains. But what
> syntax will you use? If I make one up for the sake of illustration:
>
At 03:55 PM 10/2/00 -0700, Nathan Wiger wrote:
> > Or are we talking apples and oranges and the above declaration is intended
> > to declare that any *member* of @a is of SomeType, never mind the array
> > itself?
>
>Yes, I think that second sentence hits the point. Currently, there's
>ambiguity a
> >However, making it a UNIVERSAL method also dictates that this:
> >
> >my SomeType @a :someattr;
> >
> >*must* be either:
> >
> >1. a builtin type
> >2. tied
> >
> >To get its attributes back out. I'm not sure this is going to always be
> >true.
>
> It must be my sinuses. I don't g
At 04:53 PM 10/1/00 -0400, Dan Sugalski wrote:
>At 11:33 AM 10/1/00 -0700, Peter Scott wrote:
>>But, setting aside my visceral reaction to changing array bases, you have
>>precisely the same problem here that has scuppered my intent to file an
>>RFC for hashes with fixed keys; how do you apply t
Jeremy Howard wrote:
>
> I haven't got around to RFCing the more generic version (that all attributes
> are inherited inside nested data types), but that would certainly be a nice
> approach.
Not to confuse, let's call it cascading instead of inheritance.
--
John Porter
Bart Lateur wrote:
>
> You don't declare Perl arrays. They just exist. Well... except for my'ed
> arrays.
>
> My idea is that if anybody sets $[ to 1 in a script, all accesses to
> array in that script would use 1 as the index of the very first item:
> $ary[1]. But if you pass this array (for ex
I should have said: file-scoped lexical.
On Sat, 30 Sep 2000 21:56:43 +0100, Nicholas Clark wrote:
>If it's lexically scoped, would it be for arrays declared in that scope, or
>for arrays accessed in that scope?
>I'm not sure. I think I see potential breakage both ways.
You don't declare Perl a
Bart Lateur wrote:
> On 30 Sep 2000 20:13:55 -, Perl6 RFC Librarian wrote:
>
> >But setting $[ = 1 is the mathematically correct method for
> >array addressing and makes it easier for ordinary mortals to do
> >basic tasks with C, array addressing and the like.
>
> I sure don't want the fact t
On Sat, Sep 30, 2000 at 09:56:43PM +0100, Nicholas Clark wrote:
> Similarly modules' formatting breaks if you set $/;
$\;
D'oh
> How many of the punctuation variables would be better with less-than-global
> scope?
Nicholas Clark
On Sat, Sep 30, 2000 at 10:34:40PM +0200, Bart Lateur wrote:
> On 30 Sep 2000 20:13:55 -, Perl6 RFC Librarian wrote:
>
> >But setting $[ = 1 is the mathematically correct method for
> >array addressing and makes it easier for ordinary mortals to do
> >basic tasks with C, array addressing and
13 matches
Mail list logo
