Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
>
>> Can someone give me a realish world example of when you would want an
>> array that can store both undefined values and default values and those
>> values are different?
>
> my @send_partner_em
Rick Delaney <[EMAIL PROTECTED]> writes:
> I'd also like to point out that ruby has defaults for hashes but
> assigning nil (the equivalent of undef) does not set the default; delete
> does.
Yeah, but Hashes aren't Arrays. And vice versa.
--
Piers
Dave Mitchell wrote:
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
IMHO some sort of proxy could be passed here, saying: "if you write to
me, this will be at @a[0]". Or auto-vivify the entry.
This is what Perl 5 does at the moment:
$ perl5.8.0 -MDevel::Peek -e 'sub f{Dum
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
> A lvalue param is not strictly reading, but here has to happen something
> differently - yes:
>
> IMHO some sort of proxy could be passed here, saying: "if you write to
> me, this will be at @a[0]". Or auto-vivify the entry.
Thi
Aaron Sherman wrote:
On Tue, 2003-01-28 at 16:23, Leopold Toetsch wrote:
Arrays (or hashes) don't grow on reading - never.
But for less pure forms of reading:
foo(@a[0]);
auto-vivification will have to happen in some cases. e.g. if foo
requires a lvalue parameter.
A lvalue param is no
On Thursday 30 January 2003 06:49 pm, Andrew Rodland wrote:
> On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote:
> > On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote:
> > > On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
> > I'd also like to point out that ruby h
On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote:
> On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote:
> > On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
> > > That would make the rule very simple indeed:
> > >
> > > Assigning C to an array element causes that
On Thu, Jan 30, 2003 at 11:41:04AM -0500, Aaron Sherman wrote:
> On Wed, 2003-01-29 at 16:41, Nicholas Clark wrote:
>
> > And the demonstration was as expected?
>
> Yes, of course. If you modify a hash, or look at another hash, you
> should not expect the same results. Why would you? More importa
On Thursday, January 30, 2003, at 12:49 PM, Austin Hastings wrote:
undef @a[5]; # undefining the element sets it to the default
@a[5]; # 2
@a[5] = undef; # same as above
@a[5]; # 2
undef!!
@a is an array of Int (not int) and can store undef, so no error occurs
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> Right, we just can't do the 'undef' thing. OK, so let me see if this
> is right yet:
>
> my Int @a is default(2);
> @a[5] = 5;
>
> @a[4]; # 2 (autofilled)
> @a[5]; # 5
> @a[6]; # 2 (out-of-bounds)
>
>
At 10:54 AM -0800 1/30/03, Mark Biggar wrote:
and if we define a prop "is no_default" then you get what ever
junk happens to be in memory. (this for even more speed)
That's not going to happen. It's too unsafe, and too open to
corruption attacks.
--
Dan
On Thursday, January 30, 2003, at 10:56 AM, Austin Hastings wrote:
There is no reason why primitive-typed arrays can't have a default. It
is the confusion of "default" with "undef" that is causing this
problem.
Yes, I misspoke. You can have a default, which it will use for
autofill & out-of-
Austin Hastings wrote:
There is no reason why primitive-typed arrays can't have a default. It
is the confusion of "default" with "undef" that is causing this
problem.
If I have:
my int @a;
print @a[4];
What comes out?
Notice, there's no "is default(woo-woo)" in there. Just a plain old
primit
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Thursday, January 30, 2003, at 12:03 AM, Leopold Toetsch wrote:
> > Why do you then use a primitive type in the first place?
> >
> > IMHO:
> >
> > 1) primitive types are what they are - no undef, no attributes,
> just
> > e.g. plain integers
On Thursday, January 30, 2003, at 09:55 AM, Dan Sugalski wrote:
At 9:53 AM -0800 1/30/03, Michael Lazzaro wrote:
This is leading me to the conclusion that primitive-typed arrays
should not be allowed to have defaults, period, and that attempting
to place one should be a compile-time error.
At 9:53 AM -0800 1/30/03, Michael Lazzaro wrote:
This is leading me to the conclusion that primitive-typed arrays
should not be allowed to have defaults, period, and that attempting
to place one should be a compile-time error. If you want a default,
use C instead of an C, and it will work fine
On Thursday, January 30, 2003, at 12:03 AM, Leopold Toetsch wrote:
Why do you then use a primitive type in the first place?
IMHO:
1) primitive types are what they are - no undef, no attributes, just
e.g. plain integers (or shorts or bits ...)
2) if you want to store additional information us
At 11:41 AM -0500 1/30/03, Aaron Sherman wrote:
On Wed, 2003-01-29 at 17:12, Dan Sugalski wrote:
At 12:40 PM -0500 1/29/03, Aaron Sherman wrote:
>Elements of a has ARE ordered, just not the way you may expect.
Just to nip this one in the bud...
The bud was back that-a-way about 3 days
On Wed, 2003-01-29 at 17:50, Spider Boardman wrote:
> On 29 Jan 2003 14:29:52 -0500, Aaron Sherman wrote (in part):
>
> ajs> As for the argument that testing for true non-existentness is a
> ajs> burden, check out the way Perl5 does this. Hint: there's a central
> ajs> sv_undef, and that's not wh
On Wed, 2003-01-29 at 17:12, Dan Sugalski wrote:
> At 12:40 PM -0500 1/29/03, Aaron Sherman wrote:
> >Elements of a has ARE ordered, just not the way you may expect.
>
> Just to nip this one in the bud...
The bud was back that-a-way about 3 days
> If people start assuming that there's *any*
On Wed, 2003-01-29 at 16:41, Nicholas Clark wrote:
> And the demonstration was as expected?
Yes, of course. If you modify a hash, or look at another hash, you
should not expect the same results. Why would you? More importantly, why
would the conversation threat up until now lead to such an exampl
On 29 Jan 2003 14:29:52 -0500, Aaron Sherman wrote (in part):
ajs> As for the argument that testing for true non-existentness is a
ajs> burden, check out the way Perl5 does this. Hint: there's a central
ajs> sv_undef, and that's not what array buckets are initialized to
Either you're dead wr
Jonathan Scott Duff wrote:
The solution I advocate is to allow even "primitive" types to hold
undef.
Why do you then use a primitive type in the first place?
IMHO:
1) primitive types are what they are - no undef, no attributes, just
e.g. plain integers (or shorts or bits ...)
2) if you w
"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Wed, Jan 29, 2003 at 11:32:53AM -0800, Michael Lazzaro wrote:
> >
> > Agreed, it's not pretty. The fundamental problem is that a primitive
> > like an C simply cannot be undefined... there'
On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote:
>
> On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
> > That would make the rule very simple indeed:
> >
> > Assigning C to an array element causes that element to take
> > the
> > array's default value.
> >
> > The
On Wed, Jan 29, 2003 at 02:37:04PM -0600, Jonathan Scott Duff wrote:
> On Wed, Jan 29, 2003 at 03:29:57PM -0500, Aaron Sherman wrote:
> > On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
> >
> > > Can someone give me a realish world example of when you would want an
> > > array that can sto
At 2:18 PM -0800 1/29/03, Austin Hastings wrote:
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 10:59 AM -0800 1/29/03, Austin Hastings wrote:
>Now: Does this require a "fake undef" and a "real undef"?
>
>WHO CARES?
Very good answer. Leave the details to me and the p6i folks. (Though
do pl
On Wed, Jan 29, 2003 at 02:13:34PM -0600, Jonathan Scott Duff wrote:
> On Wed, Jan 29, 2003 at 12:00:33PM -0800, Mark Biggar wrote:
> > In my opinion, default values for arrays should only come into play
> > for array elements that have NEVER been assigned to or that have
> > been explicity undef'e
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:59 AM -0800 1/29/03, Austin Hastings wrote:
> >Now: Does this require a "fake undef" and a "real undef"?
> >
> >WHO CARES?
>
> Very good answer. Leave the details to me and the p6i folks. (Though
> do please, everyone, pay attention when we tel
At 12:40 PM -0500 1/29/03, Aaron Sherman wrote:
Elements of a has ARE ordered, just not the way you may expect.
Just to nip this one in the bud...
If people start assuming that there's *any* ordering to hashes, I
promise I *will* make sure that parrot's external hash class starts
returning ke
On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
That would make the rule very simple indeed:
Assigning C to an array element causes that element to take
the
array's default value.
The effects of this are:
* Assigning a particular integer to an array of int or Int always
do
On Wed, Jan 29, 2003 at 12:40:21PM -0500, Aaron Sherman wrote:
> Elements of a has ARE ordered, just not the way you may expect.
Quite:
$ perl5.8.0 -le '%a = (small => 1, large =>2); %b = %a; print foreach keys %a; print
"--"; print foreach keys %b'
large
small
--
small
large
$ perl5.8.0 -le '
On Wed, Jan 29, 2003 at 03:48:18PM -0500, Dan Sugalski wrote:
> (Though do please, everyone, pay attention when we tell you that what
> you want is slow or awkward)
Just be sure to reiterate in case we miss it the first time :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
At 10:59 AM -0800 1/29/03, Austin Hastings wrote:
Now: Does this require a "fake undef" and a "real undef"?
WHO CARES?
Very good answer. Leave the details to me and the p6i folks. (Though
do please, everyone, pay attention when we tell you that what you
want is slow or awkward)
--
On Wed, 2003-01-29 at 14:53, Austin Hastings wrote:
> Leaving out the whole "is default()" bit, what happens when I:
>
> my int @a;
> @a[4] = 100;
> @a[2];
>
> What does @a[2] return? It must return something, and that something
> can't be undef, because ... So, what is it? Whatever it
> i
> Agreed, it's not pretty. The fundamental problem is that a primitive
> like an C simply cannot be undefined... there's no flag for that
> (which is they're primitive.)
Certainly there's no way of _storing_ C.
> So it having a 'default value' at all is perhaps a bit of a misnomer.
Why does tha
On Wed, Jan 29, 2003 at 03:29:57PM -0500, Aaron Sherman wrote:
> On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
>
> > Can someone give me a realish world example of when you would want an
> > array that can store both undefined values and default values and those
> > values are different?
On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
> Can someone give me a realish world example of when you would want an
> array that can store both undefined values and default values and those
> values are different?
my @send_partner_email is default(1);
while $websignups.getline {
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote:
> > Solution 3: The autoset sets the value to the default value.
> >
> > my Int @a is default(5);
> >
> > @a[3] = 3; # there are now 4 items in the array
> >
On Wed, Jan 29, 2003 at 09:07:37PM +0100, Juergen Boemmels wrote:
> Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> > Can someone give me a realish world example of when you would want an
> > array that can store both undefined values and default values and those
> > values are different?
>
> Ok
On Wed, Jan 29, 2003 at 12:00:33PM -0800, Mark Biggar wrote:
> In my opinion, default values for arrays should only come into play
> for array elements that have NEVER been assigned to or that have
> been explicity undef'ed. If an assigment is made to an array element
> then the array element shou
In my opinion, default values for arrays should only come into play
for array elements that have NEVER been assigned to or that have
been explicity undef'ed. If an assigment is made to an array element
then the array element should end up the assigned value (modulo
necessary type conversions) and
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote:
> > Solution 3: The autoset sets the value to the default value.
> >
> > my Int @a is default(5);
> >
> > @a[3] = 3; # there are now 4 items in the array
> > @a
On Wed, Jan 29, 2003 at 11:32:53AM -0800, Michael Lazzaro wrote:
>
> On Wednesday, January 29, 2003, at 11:02 AM, Jonathan Scott Duff wrote:
> >> So you can't set something to its type's own empty value, because it
> >> will, by definition, thereafter return it's "overloaded" empty value,
> >> .
On Wed, Jan 29, 2003 at 08:49:42PM +0100, Juergen Boemmels wrote:
> Solution 3: The autoset sets the value to the default value.
>
> my Int @a is default(5);
>
> @a[3] = 3; # there are now 4 items in the array
> @a[2]; # was autoset 5 so returns 5
> @a[4];
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Wednesday, January 29, 2003, at 11:02 AM, Jonathan Scott Duff
> wrote:
> >> So you can't set something to its type's own empty value, because
> it
> >> will, by definition, thereafter return it's "overloaded" empty
> value,
> >> .
> >
> > Loo
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty
> value', 5
>
> @a[5] = undef;
Ok, stepping back...
there are three questions:
* Can a type be undefined
* What does an array say when asked for an element that doesn't exist
* What happens when you try to undefine something
I really think you need an attribute to clarify these.
For example, you would not say:
my in
On Wednesday, January 29, 2003, at 11:02 AM, Jonathan Scott Duff wrote:
So you can't set something to its type's own empty value, because it
will, by definition, thereafter return it's "overloaded" empty value,
.
Looks like a maintenance nightmare to me.
Agreed, it's not pretty. The fundame
On Wed, Jan 29, 2003 at 10:23:26AM -0800, Michael Lazzaro wrote:
> OK, I think we agree that 'default' refers to what to put in the
> 'holes' of an array (or hash, but that's a separate discussion.) When
> you overlay a real hash on top of your default values, the default
> values "show through
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> OK, I think we agree that 'default' refers to what to put in the
> 'holes' of an array (or hash, but that's a separate discussion.)
> When
> you overlay a real hash on top of your default values, the default
> values "show through the holes".
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty value',
>
> 5
> @a[5] = undef;# autocnv to 0, + warning, still sets to
> 5
>
OK, I think we agree that 'default' refers to what to put in the
'holes' of an array (or hash, but that's a separate discussion.) When
you overlay a real hash on top of your default values, the default
values "show through the holes". So now we just have to define what
"holes" are.
An asser
Ok, I'll respond to a couple of points, below, but I think a lot of
folks are confusing some operational concepts here, and it's getting
hard to un-peel them.
A container has many attributes, even if Perl won't let us control them.
Those include:
1. Storage
2. Conversion of the wh
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> Can I flame you for being too preemptive? :-)
In all honesty, I just wanted to be able to use "absquatulate" in a
real post. ;-)
=Austin
On 2003-01-29 at 10:32:58, Mark J. Reed wrote:
> (What their value should be is the subject of the
> parallel thread on array defaults).
Whups, that would be THIS thread, actually. The sidebar on
removing the syntactic distinction between arrays and hashes
made me think I was over in the "Spare
On 2003-01-29 at 09:44:27, Aaron Sherman wrote:
> Yes, I would expect that. In my opinion there is no difference between
> an array and a hash other than the underlying storage and the
> type-management of the key.
Perhaps it is your opinion that those should be the only differences,
but the actua
On Tue, 2003-01-28 at 19:24, Paul Johnson wrote:
> > If that's not the case, I need to get my head around why, since Perl
> > *does* distinguish between defined and exists.
>
> But I wish it wouldn't for arrays. That only came about to support
> pseudo-hashes which are going / have gone away.
>
attriel wrote:
So ... with the discussion of "what if i really wanted to put an undef in
there b/c it's not just that i haven't defined it but rather that it
really isn't defined. I KNOW it's not defined, and i'm now explicitly
saying it's undefined as opposed to before when i was implicitly
sug
So ... with the discussion of "what if i really wanted to put an undef in
there b/c it's not just that i haven't defined it but rather that it
really isn't defined. I KNOW it's not defined, and i'm now explicitly
saying it's undefined as opposed to before when i was implicitly
suggesting that i di
Aaron Sherman wrote:
auto-vivification will have to happen in some cases. e.g. if foo
requires a lvalue parameter. You can't know if an actual write will
happen, so you have to auto-vivify in order to pass a reference.
Or did I miss something there?
I think the idea is to use a special object
Michael Lazzaro wrote:
2a) When a cell is explicitly re-undefined, does the default value take
effect?
my @a is Array( default => 'foo' ) = (1,2,3);
@a[1] = undef;
@a[1]; # undef, or 'foo'?
STRAWMAN ANSWER: 'foo'.
If C is a valid value for a cell, then I should be able
Michael Lazzaro wrote:
The next (oft-asked) question is whether or not C denotes
read-only, or if you can store to an C array.
my @a is computed { $^index**2 };
@a[4] = 'something completely different';
I'd expect that C and C would be orthogonal.
And things like this would be downri
On Tue, Jan 28, 2003 at 03:06:19PM -0800, Damian Conway wrote:
> Austin Hastings wrote:
>
> >--- Damian Conway <[EMAIL PROTECTED]> wrote:
> >
> >>my @a is default(666);
> >>
> >>print @a[2];# prints 666
> >>
> >>@a[4] = 1;
> >>
> >>print @a[2];# now prints undef :-(
>
> [t
On Tue, Jan 28, 2003 at 04:07:17PM -0500, Aaron Sherman wrote:
> I think this debate is easier if you think of defaults as overriding and
> auto-vivification method on a container.
Hmm. I don't :-)
I think it is easier if you think of defaults as overriding undef.
> On Tue, 2003-01-28 at 14:47
Nicholas Clark wrote:
> I'm not sure. I think I like the idea of
>
> @a[0] = undef;
>
> being a blip, but
>
> undef @a[0];
>
> resetting the value to the default.
That thought crossed my mind as well before I got to your message ...
> Conceptually perl5 already has a distinction between
Austin Hastings wrote:
--- Damian Conway <[EMAIL PROTECTED]> wrote:
my @a is default(666);
print @a[2]; # prints 666
@a[4] = 1;
print @a[2]; # now prints undef :-(
[typo in third line corrected]
I don't understand your example. Can you explain it again, using words
of less than one
On Tue, Jan 28, 2003 at 02:13:22PM -0800, Michael Lazzaro wrote:
> Hmm. I don't have a strong preference either way, but I'm not sure why
> (given C):
>
>@a[ undef ]
>
> C should be autoconverted to 0 with warning, but in:
>
>@a[0] = undef;
>
> C should _not_ be autoconverted to 0, b
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Tuesday, January 28, 2003, at 01:01 PM, Nicholas Clark wrote:
> > On Tue, Jan 28, 2003 at 12:30:41PM -0800, Austin Hastings wrote:
> >> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> >>> my int @a is Array( default => 5 );
> >>> @
Austin Hastings wrote:
> --- Austin Hastings <[EMAIL PROTECTED]> wrote:
>
> > No, undef. OTOH, deleting @a[1] would reset it to default.
>
> Ere someone flames my for using a hash keyword in an array context:
>
> s/deleting/absquatulating (e.g., via pop, shift, or splice)/
What's wrong with C
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
> > --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> >
> >
> >>No, undef. OTOH, deleting @a[1] would reset it to default.
> >
> >
> > Ere someone flames my for using a hash keyword in an array context:
> >
> > s/deleting/ab
On Tuesday, January 28, 2003, at 01:01 PM, Nicholas Clark wrote:
On Tue, Jan 28, 2003 at 12:30:41PM -0800, Austin Hastings wrote:
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
my int @a is Array( default => 5 );
@a[0] = undef;
This should cause a blip of some kind. If storing an e
On Tuesday, January 28, 2003, at 01:14 PM, Damian Conway wrote:
I'm not compelled by the counter-argument that this makes it
impossible to store an C in an array with a default. Because
the whole point of an array having a default is to prevent those nasty
out-of-range Cs from popping up in t
On Tue, 2003-01-28 at 16:23, Leopold Toetsch wrote:
> Austin Hastings wrote:
>
>
> > Another question: If you ask for a value and get it, does the array
> > grow? Or does that happen only on assignment? (
>
>
> Arrays (or hashes) don't grow on reading - never.
Never say never. You're correct f
Austin Hastings wrote:
Another question: If you ask for a value and get it, does the array
grow? Or does that happen only on assignment? (
Arrays (or hashes) don't grow on reading - never.
And another anser from current low level (list.c & classes/Array.pmc)
*Return value
*---
On Tue, Jan 28, 2003 at 12:30:41PM -0800, Austin Hastings wrote:
>
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> > my int @a is Array( default => 5 );
> > @a[0] = undef;
>
> This should cause a blip of some kind. If storing an explicit undef (as
> opposed to "undef but 0" or C<$v
Austin Hastings wrote:
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
No, undef. OTOH, deleting @a[1] would reset it to default.
Ere someone flames my for using a hash keyword in an array context:
s/deleting/absquatulating (e.g., via pop, shift, or splice)/
Unfortunately, I don't think we
I think this debate is easier if you think of defaults as overriding and
auto-vivification method on a container.
On Tue, 2003-01-28 at 14:47, Paul Johnson wrote:
> Michael Lazzaro said:
> > 2a) When a cell is explicitly re-undefined, does the default value take
> > effect?
> >
> > my @a is
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> No, undef. OTOH, deleting @a[1] would reset it to default.
Ere someone flames my for using a hash keyword in an array context:
s/deleting/absquatulating (e.g., via pop, shift, or splice)/
=Austin
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> 1) What's the final decided syntax? Two possibilities:
>
> my @a is Array( default => 'foo' ); # attrib?
> my @a is default('foo');# property?
Since we want arrays (lowercase) to support them, too, it should be a
pro
Michael Lazzaro said:
>
> There has been discussion of allowing a "default" value for array cells
> -- that is, one aside from C or whatever the type-specific
> default is. Questions, in order of increased evilness:
1 and 2 seem fine to me.
> 2a) When a cell is explicitly re-undefined, does th
On Tue, Jan 28, 2003 at 01:30:54PM -0600, Jonathan Scott Duff wrote:
> On Tue, Jan 28, 2003 at 11:15:26AM -0800, Michael Lazzaro wrote:
> > 2) Assume the default value is a simple value, e.g. 'foo'.
> >
> > my @a is Array( default => 'foo' );
> > @a[5] = 'bar';
> >
> > @a[4]; #
On Tue, Jan 28, 2003 at 11:15:26AM -0800, Michael Lazzaro wrote:
> 2) Assume the default value is a simple value, e.g. 'foo'.
>
> my @a is Array( default => 'foo' );
> @a[5] = 'bar';
>
> @a[4]; # 'foo'
> @a[5]; # 'bar'
> @a[6]; # 'foo'
>
> @a[-1];# '
There has been discussion of allowing a "default" value for array cells
-- that is, one aside from C or whatever the type-specific
default is. Questions, in order of increased evilness:
1) What's the final decided syntax? Two possibilities:
my @a is Array( default => 'foo' ); # attri
84 matches
Mail list logo
