On 28 Jan 2003, Aaron Sherman wrote:
I'm not sure I recall the sufficient, yet irrelevant technical reasons.
I certainly can't think of anything. It also helps in the case of
objects that are non truly arrayish or hashish:
my SuperTree $foo;
$foo[Munge]; # Returns the node whose
On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
This may sound like a silly idea but ...
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?
PHP works this way.
In particular, it would seem that
%foo[$key]
would be just as easy for the compiler to grok as
%foo{$key}
On Mon, 27 Jan 2003 15:39:19 -0800, Damian Conway [EMAIL PROTECTED] wrote:
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Yes, well I suppose that could be
On Wed, 29 Jan 2003 18:04, Michael G Schwern wrote:
On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
This may sound like a silly idea but ...
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and
John Williams wrote:
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates 1,234,567 elements!
Not currently: 2) does
- generate a sparse hole
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.
Are
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 actual
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
--- Sam Vilain [EMAIL PROTECTED] wrote:
=head2 includes( [ Ikeys, ] [ Ivalues ])
Where the keys and/or values are obviously junctions.
if ($container.includes(any(ant, beaver, cow, duck))(
...
This is *SO* cool.
=Austin
--- 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
--- Nicholas Clark [EMAIL PROTECTED] wrote:
On Tue, Jan 28, 2003 at 09:17:36AM -0800, Damian Conway wrote:
Errno. That's rather the whole point of Cbut properties [*].
[*] People, we just *have* to find better names for these things!
I'd suggest we henceforth call them value
On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote:
Obviously, values are pure and therefrom spring virtues, while
objects are but vile clay -- fallible constructs of a sinful man,
pathetically trying to recreate an envisioned ideal. Ergo, they have
naught but vices.
Can I get
--- Nicholas Clark [EMAIL PROTECTED] wrote:
On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote:
Obviously, values are pure and therefrom spring virtues, while
objects are but vile clay -- fallible constructs of a sinful man,
pathetically trying to recreate an envisioned ideal.
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
On Wed, Jan 29, 2003 at 03:52:22PM +, Nicholas Clark wrote:
On Wed, Jan 29, 2003 at 07:46:43AM -0800, Austin Hastings wrote:
Obviously, values are pure and therefrom spring virtues, while
objects are but vile clay -- fallible constructs of a sinful man,
pathetically trying to recreate
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
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
my
--- 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. So now
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 the
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,
def.
Looks like a maintenance nightmare to me.
Agreed, it's not pretty. The
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
On Wed, 2003-01-29 at 05:29, Leopold Toetsch wrote:
John Williams wrote:
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates
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;#
--- 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,
def.
Looks like a
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]; #
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,
def.
Looks
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[2];
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
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 should
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, here is
Michael G Schwern wrote:
On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
Has anyone considered removing with the syntactic distinction
between numeric and string indexing -- that is, between array and
hash lookup?
PHP works this way.
Well, for some definition of
--- 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
@a[2];
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 {
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?
my
Agreed, it's not pretty. The fundamental problem is that a primitive
like an Cint simply cannot be undefined... there's no flag for that
(which is they're primitive.)
Certainly there's no way of _storing_ Cundef.
So it having a 'default value' at all is perhaps a bit of a misnomer.
Why
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 ... above So, what is it? Whatever it
is,
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, 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]
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 '%a =
On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote:
That would make the rule very simple indeed:
Assigning Cundef 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
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
--- 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 tell you that what
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'ed. If
On Wed, Jan 29, 2003 at 09:44:27AM -0500, 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. I'm increasingly of the opinion that a)
there should be no @ vs %,
Stéphane Payrard wrote:
On Wed, Jan 29, 2003 at 09:44:27AM -0500, 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. I'm increasingly of the opinion that a)
there
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 please,
Date: Mon, 27 Jan 2003 13:24:23 -0800
From: Damian Conway [EMAIL PROTECTED]
Dave Whipp suggested:
The size constraints are probably Cbut properties, as is Clocked. The
exception behavior probably deserves to remain an Cis property.
Nope. They're all Cis properties. Cbut properties
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 store both
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 Cundef to an array element causes that element to take
the
array's default value.
The effects
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 Cint simply cannot be undefined... there's no
50 matches
Mail list logo
