Re: Resizable array questions
Simon Glover [EMAIL PROTECTED] wrote: 1) When we resize a Resizable*Array (where * = Integer, Float or String) by calling set_integer_native, we also set the PMC's active_destroy flag. However, we don't do this when resizing a ResizablePMCArray (which also has a different memory allocation strategy). Is this because we don't strictly need to, or is this just an oversight? Just an oversight as well as in FixedPMCArray. 2) Why does the ResizablePMCArray PMC use a different memory allocation strategy, i.e. what advantage does it have over the strategy used by the other Resizable arrays? Just doubling the allocation size isn't a really good strategy beyond some big size. So I've implemented a IMHO better strategy in the PMCArray. Additionally the helper structure Size*Data isn't really needed. Simon leo
Resizable array questions
1) When we resize a Resizable*Array (where * = Integer, Float or String) by calling set_integer_native, we also set the PMC's active_destroy flag. However, we don't do this when resizing a ResizablePMCArray (which also has a different memory allocation strategy). Is this because we don't strictly need to, or is this just an oversight? 2) Why does the ResizablePMCArray PMC use a different memory allocation strategy, i.e. what advantage does it have over the strategy used by the other Resizable arrays? Simon
Re: Array Questions
Michael Lazzaro wrote: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; Syntax error, I'd expect. Though the desired effect could probably be achieved with the Cprop meta-property: my $b is prop($a); Damian
Re: Array Questions
Jonathan Scott Duff wrote: will this: my $a $b; be illegal? I certainly hope so! Damian
Re: Array Questions
Piers Cawley observed: BTW, Cmy Foo $a is Foo is just sick! (i.e. I'll *definitely* be using it ;-) Surely anyone who does C my Array @foo , or C my Scalar $foo will be using it, albeit indirectly. Of course, but without the brain-twisting effect of the repeated classname. ;-) Damian
Re: Array Questions
[EMAIL PROTECTED] (Michael Lazzaro) writes: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; I think at this stage it's probably worth reminding everyone that not every string of characters *needs* to be syntactically valid Perl 6, despite our best efforts. -- Do not meddle in the affairs of cats, for they are subtle and will piss on your computer. --Bruce Graham
Re: Array Questions
Michael Lazzaro [EMAIL PROTECTED] writes:
On Thursday, January 9, 2003, at 03:24 AM, Damian Conway wrote:
Michael Lazzaro asked:
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
Yes.
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Indeed
Great -- then I have only one more question, I think. In the words of
a certain cartoon character, what's *this* button do?
my $b is $a;
Compile time error. 'is' is a compile time property, scalar values
aren't.
Re: Array Questions
Damian Conway [EMAIL PROTECTED] writes: Michael Lazzaro wrote: Which, in turn, implies that the lines: my Foo $a; # (1) my $a is Foo; # (2) my Foo $a is Foo; # (3) are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1) does not. Correct. Though the instantiated Foo is the implementation object and not directly accessible (just as the implementation object in a Perl 5 tie isn't). BTW, Cmy Foo $a is Foo is just sick! (i.e. I'll *definitely* be using it ;-) Surely anyone who does C my Array @foo , or C my Scalar $foo will be using it, albeit indirectly.
Re: Array Questions
On Tuesday, January 14, 2003, at 02:24 AM, Piers Cawley wrote: Michael Lazzaro [EMAIL PROTECTED] writes: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; Compile time error. 'is' is a compile time property, scalar values aren't. That's what I first thought, but... why is that a compiletime error, if the previous example my %data is FileBasedHash($path); is not? Or, to rephrase the question, I would assume that the above allows $path to be resolved runtime, not just compiletime, or its utility seems sadly limited. So if implementor classes can be instantiated at runtime, are they really Cis compile-time properties, or are they 'is' meaning 'isa', and is that runtime-settable? [*1] (Thinking aloud) Perhaps this is an example of why having both is and isa as keywords might be a good idea. Because 'is' implies compiletime, but implementor classes aren't really properties, they're a form of (pseudo?)inheritance. So maybe my %data isa FileBasedHash($path); -or- my $b isa $a; Might be clearer(???) than reusing Cis for this purpose. Dunno. [*2] MikeL [*1] It almost seems like my %data but FileBasedHash($path); would be more appropriate, but I think we can agree that's *horrid*. [*2] This ties strongly into the whole issue of allowing some form of prototype-based (classless) inheritance. I try to avoid it, but damn it, *it keeps pulling me back in*! Right now I just need to know what 'is' is, for the sake of arrays and hashes. :-/
Re: Array Questions
At 9:23 AM -0800 1/14/03, Michael Lazzaro wrote: On Tuesday, January 14, 2003, at 02:24 AM, Piers Cawley wrote: Michael Lazzaro [EMAIL PROTECTED] writes: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; Compile time error. 'is' is a compile time property, scalar values aren't. That's what I first thought, but... why is that a compiletime error, if the previous example my %data is FileBasedHash($path); is not? I'm not sure either of them *has* to be an error, as the compile-time properties that is imparts need to be evalutated and applied at runtime. The my $foo is $bar would mean that we couldn't do any compile-time type checking, but that's not a huge deal as presumably you wouldn't *want* any type checing in that case. Whether it is a good idea or not from a maintenance/programmer-brain standpoint is a separate issue. I think I'd rather dislike having to maintain code that did it, but I can see a few good reasons to do it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Array Questions
Luke Palmer wrote:
I would imagine that would only work if $a was known at compile time:
I think we could do it at runtime too. You could conceivably use
runtime resolution to, for example, choose from between several
different caching behaviors to be passed to a complex routine:
sub get_cached_foo( HashImplementor $implementor ) {# syntax???
my %foo is $implementor;
...
return \%foo;
}
my $foo = get_cached_foo( LRU_Cache );
That should be OK... we have to know what C$implementor is when we
actually do the Cmy %foo, but it doesn't have to be known at compiletime.
My only concern with this particular example:
my $a = MyCache; # (1) $a contains a class identifier
my %b is $a; # (2)
vs.
my $a = 'MyCache'; # (3) $a contains a string
my %b is $a; # (4)
is that 1-2 should work as intended, but 3-4 probably doesn't... because
in (3) $a is just a string, *not* a class. Since a string instance
doesn't implement the interface to be a Scalar implementor, (4) would
give a runtime error. So I *think* the first example should work, and
the second example should not.
Actually, that's quite a difficult question; is MyScalar a
property or a behavior class? Is there a difference, or is the latter
a subset of the former?
Yeah. In the words of another cartoon character, I *don't* know.
:-/
MikeL
Re: Array Questions
On Thursday, January 9, 2003, at 03:24 AM, Damian Conway wrote:
Michael Lazzaro asked:
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
Yes.
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Indeed
Great -- then I have only one more question, I think. In the words of
a certain cartoon character, what's *this* button do?
my $b is $a;
My presumption:
1) If Cmy $a = MyScalar, e.g. $a is set to a class name, it's saying
that $b is implemented by a MyScalar. But I don't know if these two
lines would really have the same result, given rule (2), below:
$a = MyScalar;
$a = 'MyScalar';
2) If Cmy $a = $fooObj, e.g. it's set to an arbitrary object
instance, it's saying that $b is implemented by the object instance in
$a. So these statements are equiv:
my $a = FileBasedHash.new($path);
my %b is $a;
vs.
my %b is FileBasedHash($path);
If the object in $a doesn't implement the Scalar interface, it's a
runtime error. And note that Cmy %b is %a would be a runtime error,
one would hope.
MikeL
(My original gut desire was that Cmy $b is $a be the ultracool perl6
way of achieving prototype-based (classless) OO, such that $b inherits
its base functionality from $a. As inherently cool as that is, I don't
think that can possibly work, and it would conflict *severely* with
these other meanings. Ah, well.)
Re: Array Questions
On Fri, Jan 10, 2003 at 10:28:49AM -0800, Michael Lazzaro wrote: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; And no matter what that button does, will this: my $a $b; be illegal? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Array Questions
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]] But I don't know if these two lines would really have the same result, ... $a = MyScalar; $a = 'MyScalar'; Hrmm. Didn't Larry decree that there are no bare words, but that a class name will evaluate to the string representing the spelling of the class name? In otherwords, aren't those two assignments identical by definition? =thom Never try to out-stubborn a cat. --Lazarus Long
Re: Array Questions
From: Thom Boyer [EMAIL PROTECTED]
Date: Fri, 10 Jan 2003 13:57:26 -0700
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
But I don't know if these two
lines would really have the same result, ...
$a = MyScalar;
$a = 'MyScalar';
Hrmm. Didn't Larry decree that there are no bare words, but that a class
name will evaluate to the string representing the spelling of the class
name? In otherwords, aren't those two assignments identical by definition?
You're correct in that there are no barewords. But, IIRC, a class
name doesn't just evaluate to a string representing the spelling of
the class name. Classes are first-class objects in Perl 6, just as
subroutines were in Perl 5.
The two variables would only behave the same in certain situations
because of symbolic dereferencing. But, they couldn't go by name,
because then what would $foo be here:
$foo = class { has $.bar is public };
As far as the example:
$a = MyScalar;
$b = $a is $a;
(Or something like that) I would imagine that would only work if $a
was known at compile time:
BEGIN { $a = MyScalar; }
$b = $a is $a;
Maybe. Actually, that's quite a difficult question; is MyScalar a
property or a behavior class? Is there a difference, or is the latter
a subset of the former?
But, AFAIK, the two statements are not equivalent.
Luke
Re: Array Questions
Michael Lazzaro asked:
OK, next question. Is _THIS_ possible?
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
Yes. Though we would need a syntax for specifying that string parameter for the
generic CFileBasedHash class. And, of course, a mechanism for constructing the
non-generic version of the generic class from the corresponding argument.
And if _that's_ possible, is _THIS_ possible?
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Indeed. In fact, there may even be a standard property that does this kind of
thing:
# Note: this is purely speculative...
my $str is from($filename); # text in file becomes chars in string
my @lines is from($filename); # lines in file become elements in array
my %config is from($filename); # colon-separated fields in file become kv pairs in hash
Damian
Re: Array Questions
Michael Lazzaro wrote:
my int @a;
my @a returns int;
my @a is Array of int;
my @a is Array returns int;
my int @a is Array;
Those lines are all absolutely synonymous, and all declare an array of
integers, right?
Right. (This week, at least ;-)
Likewise, Arrays have methods:
my int @a = (1..100);
print @a.length; # prints 100
my @b = @a.grep { $_ 50 }; # gets 51..100
... which is also known, based on previous Apocalypsii.
Right.
If we accept those as valid syntax -- and I *think* they have been --
then P6 Arrays are objects. Or, at minimum, they cannot be _discerned_
from objects, regardless of implementation.
The later, I strongly suspect.
The remaining big question, then, is whether you can truly subclass
Array to achieve Ctie-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has to be possible.
Which, in turn, implies that the lines:
my Foo $a; # (1)
my $a is Foo; # (2)
my Foo $a is Foo; # (3)
are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1)
does not.
Correct. Though the instantiated Foo is the implementation object and
not directly accessible (just as the implementation object in a Perl 5
tie isn't).
BTW, Cmy Foo $a is Foo is just sick!
(i.e. I'll *definitely* be using it ;-)
Damian
Re: Array Questions
Jonathan Scott Duff wrote: On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote: Which, in turn, implies that the lines: my Foo $a; # (1) my $a is Foo; # (2) my Foo $a is Foo; # (3) are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1) does not. Um ... ick. I'd hope that autoinstantiation wouldn't happen without some clear syntactical clue. (I don't think is that clue. To me all three of those look like they should just earmark $a to contain a Foo and this Foo-thing can/will be instantiated later) I doubt it. The Cis Foo tells Perl that this variable is *implemented* by a (hidden) Foo object. The variable better be able to get in touch with that inner Foo at the point the variable is first used in any way. So it probably needs to be autocreated at the point of declaration (or, at least, trampolined into existance before the variable is first used). Damian
Re: Array Questions
From: Deborah Ariel Pickett [EMAIL PROTECTED] Date: Wed, 8 Jan 2003 09:42:18 +1100 (EST) [...] But everybody has to learn Perl once. I agree with you entirely :) Luke
Re: Array Questions
On Wednesday, January 8, 2003, at 02:17 AM, Damian Conway wrote: Jonathan Scott Duff wrote: On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote: Which, in turn, implies that the lines: my Foo $a; # (1) my $a is Foo; # (2) my Foo $a is Foo; # (3) are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1) does not. Um ... ick. I'd hope that autoinstantiation wouldn't happen without some clear syntactical clue. (I don't think is that clue. To me all three of those look like they should just earmark $a to contain a Foo and this Foo-thing can/will be instantiated later) I doubt it. The Cis Foo tells Perl that this variable is *implemented* by a (hidden) Foo object. The variable better be able to get in touch with that inner Foo at the point the variable is first used in any way. So it probably needs to be autocreated at the point of declaration (or, at least, trampolined into existance before the variable is first used). Yes, I should have used something more clear than Foo, and it would have been more obvious what I was getting at: my MyScalar $a; # (1) my $a is MyScalar; # (2) my MyScalar $a is MyScalar; # (3) (1) creates a scalar variable that may store a MyScalar value. (2) creates an untyped variable in which the scalar variable $a is _implemented_ by an instance of class MyScalar. (3) creates a variable that stores a MyScalar AND is implemented by an instance of class MyScalar. Note that (3) is just plain sadistic. My point was simply that scalars, like arrays and hashes, also should use the 'is' syntax to declare an implementor class, and that the implementor class is, by necessity, always autoinstanciated. E.G. this is what our new Ctie syntax is gonna look like, fates willing. MikeL
Re: Array Questions
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve Ctie-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has to be possible.
OK, next question. Is _THIS_ possible?
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
And if _that's_ possible, is _THIS_ possible?
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Sorry, but I gotta ask. :-)
MikeL
Re: Array Questions
On Wednesday, January 8, 2003, at 01:32 PM, Michael Lazzaro wrote:
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve Ctie-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has to be possible.
OK, next question. Is _THIS_ possible?
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
And if _that's_ possible, is _THIS_ possible?
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Sorry, but I gotta ask. :-)
I would ask, if it's possible to inherit from Array or Hash, is it
possible to inherit from one which has a constrained storage type?
my WeirdHash is int Hash { ... }
Re: Array Questions
On Wednesday, January 8, 2003, at 10:39 AM, Chris Dutton wrote:
I would ask, if it's possible to inherit from Array or Hash, is it
possible to inherit from one which has a constrained storage type?
my WeirdHash is int Hash { ... }
Yes, I think that was tentatively confirmed a while back. But it would
be spelled:
class WierdHash is Hash of int { ... }
such that:
my %h is WierdHash; # automatically stores ints!
my str %h is WierdHash; # but this is probably an error
MikeL
Array Questions
I think this may be another case of it depends on what the word
'object' means, e.g. we're talking past each other. I hope.
Let's operate from the assumption -- or somebody please CORRECT ME IF
I'M WRONG -- that the following syntax is valid:
my int @a;
my @a returns int;
my @a is Array of int;
my @a is Array returns int;
my int @a is Array;
Those lines are all absolutely synonymous, and all declare an array of
integers, right? Likewise, Arrays have methods:
my int @a = (1..100);
print @a.length; # prints 100
my @b = @a.grep { $_ 50 }; # gets 51..100
... which is also known, based on previous Apocalypsii.
If we accept those as valid syntax -- and I *think* they have been --
then P6 Arrays are objects. Or, at minimum, they cannot be _discerned_
from objects, regardless of implementation.
Now, what that looks like in Parrot I have no idea. But I'm assuming
those all will work in P6, because (again, correct me if I'm wrong)
Larry has stated they will.
Is there ANY QUESTION about ANY of that? If so, please let me know
NOW, because the documentation group will writing up the 'Array' and
'Hash' sections in the coming weeks.
The remaining big question, then, is whether you can truly subclass
Array to achieve Ctie-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
It would seem remarkable if you *couldn't*, right? BUT, that's
pointing out something that might be unexpected... it's actually
instantiating a MyArray object for @a, without you having to do it
yourself. Or it's marking that @a will be instantiated upon first use.
The same thing happens when you say Cmy @a is Array, or even just
Cmy @a -- it's fundamental to the syntax.
And that would imply you can do the same for hashes, and even scalars.
Including arbitrary objects, yes?
my $a is Scalar; # long way of saying Cmy $a
my $a is int;
my $a is Scalar of int; # long way of saying Cmy int $a?
my $a is Scalar returns int; # long way of saying Cmy int $a?
my $a is MyClass;# works for anything
my $a is MyClass('a','b','c'); # so is this OK too?
Which, in turn, implies that the lines:
my Foo $a; # (1)
my $a is Foo; # (2)
my Foo $a is Foo; # (3)
are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1)
does not.
There's a lot of implications here, but it seems self-consistent, based
on sound fundamentals, and all of it seems to be either directly stated
or strongly implied by previous A's and E's and p6l threads. PLEASE
tell me if/where I'm wrong here, ASAP.
MikeL
Re: Array Questions
On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote:
I think this may be another case of it depends on what the word
'object' means, e.g. we're talking past each other. I hope.
Let's operate from the assumption -- or somebody please CORRECT ME IF
I'M WRONG -- that the following syntax is valid:
my int @a;# 1
my @a returns int;# 2
my @a is Array of int;# 3
my @a is Array returns int; # 4
my int @a is Array; # 5
Those lines are all absolutely synonymous, and all declare an array of
integers, right?
Doesn't jive with me. I'm not sure what returns int means and numbers
5 and 1 don't read well. The first one says (to me) that this thing
called @a is an int. It doesn't say anything about the contents of @a.
#5 has the same problem.
If this is one of those set-in-molded-clay kinds of things, someone
please point me at the relevant discussion.
Likewise, Arrays have methods:
my int @a = (1..100);
print @a.length; # prints 100
my @b = @a.grep { $_ 50 }; # gets 51..100
... which is also known, based on previous Apocalypsii.
If we accept those as valid syntax -- and I *think* they have been --
then P6 Arrays are objects. Or, at minimum, they cannot be _discerned_
from objects, regardless of implementation.
Now, what that looks like in Parrot I have no idea. But I'm assuming
those all will work in P6, because (again, correct me if I'm wrong)
Larry has stated they will.
Is there ANY QUESTION about ANY of that?
This all fits with my mental model (except for the declaration syntax).
The remaining big question, then, is whether you can truly subclass
Array to achieve Ctie-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
It would seem remarkable if you *couldn't*, right?
Indeed.
[ snip ]
Which, in turn, implies that the lines:
my Foo $a; # (1)
my $a is Foo; # (2)
my Foo $a is Foo; # (3)
are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1)
does not.
Um ... ick. I'd hope that autoinstantiation wouldn't happen without
some clear syntactical clue. (I don't think is that clue. To me
all three of those look like they should just earmark $a to contain a
Foo and this Foo-thing can/will be instantiated later)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Array Questions
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
Arrays have methods:
my int @a = (1..100);
print @a.length; # prints 100
my @b = @a.grep { $_ 50 }; # gets 51..100
.length is unneeded, since an array gives its length in numeric context, so
you can just say +@a. grep shouldn't be an array method either, it should be
like the perl5 grep, as it is often used on lists, grep /foo/, keys %h is
far more readable than @{[keys %h]}.grep(/foo/).
Some things should be methods on arrays though, like push, pop, shift,
unshift, and splice, since those are only for real arrays anyway.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Array Questions
On 2003-01-07 at 11:31:13, Mr. Nobody wrote:
.length is unneeded, since an array gives its length in numeric context, so
you can just say +@a.
Unneeded, but harmless.
grep shouldn't be an array method either, it should be
like the perl5 grep, as it is often used on lists, grep /foo/, keys %h is
far more readable than @{[keys %h]}.grep(/foo/).
Didn't we already have the left-to-right vs. right-to-left discussion?
Regardless of how grep works when it's not invoked as a method, it
most definitely should be invokable as one on arrays. It would probably
be defined in a superclass rather than in Array itself, assuming Array
is a specific subclass of a more general collection class
(be it List or Collection or whatever), but that doesn't matter as long
as you can call it on an array.
Also, some of the line noise in your unreadable example comes from your
mixing method syntax with other syntax. No need to do all that @{[keys %h]}
stuff - it would just be %h.keys.grep(/foo/), which looks pretty darn readable
to me.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Array Questions
On Tuesday, January 7, 2003, at 11:26 AM, Jonathan Scott Duff wrote: On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote: Let's operate from the assumption -- or somebody please CORRECT ME IF I'M WRONG -- that the following syntax is valid: my int @a;# 1 my @a returns int;# 2 my @a is Array of int;# 3 my @a is Array returns int; # 4 my int @a is Array; # 5 Those lines are all absolutely synonymous, and all declare an array of integers, right? Doesn't jive with me. I'm not sure what returns int means and numbers 5 and 1 don't read well. The first one says (to me) that this thing called @a is an int. It doesn't say anything about the contents of @a. #5 has the same problem. If this is one of those set-in-molded-clay kinds of things, someone please point me at the relevant discussion. I believe they are all set in (reasonably hard) stone. (1) is from A2/E2, and is set in granite. The other forms came post-Zurich, AFAIK -- a quick search for them finds a p6l note from Larry dated 10/10/02 (Re: Object Instanciation) that mentions them in the larger context of how objects work. (It has also been confirmed by Allison and Damian at various points, but I don't think there's ever been a post-Zurich thread devoted to it.) So yeah, I'm pretty sure they're accurate. MikeL
Re: Array Questions
On 2003-01-07 at 11:31:13, Mr. Nobody wrote: .length is unneeded, since an array gives its length in numeric context, so you can just say +@a. Unneeded, but harmless. Getting off topic here (a bit), but I think it's a Mistake to have .length mean different things on an array [Number of elements] and a (string) scalar [number of characters]. While there will never be any confusion on the part of Perl, it'll promote Thinking About Things The Wrong Way among Perl novices, who will try to think of strings as C-like arrays of characters. We've gone to great lengths to disabuse people of that notion in Perl5; let's keep it that way. Perhaps .size for number-of-elements and .length for length-of-string would work? -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] Long and wide, eternity from side to side, lead me through the rapids, guide me to the shore. There's a place that's far beyond this time and space, when each of us comes face to face with something more. - _Siren Song_, Alan Parsons
Re: Array Questions
On Tuesday, January 7, 2003, at 02:05 PM, Deborah Ariel Pickett wrote: On 2003-01-07 at 11:31:13, Mr. Nobody wrote: .length is unneeded, since an array gives its length in numeric context, so you can just say +@a. Unneeded, but harmless. Getting off topic here (a bit), but I think it's a Mistake to have .length mean different things on an array [Number of elements] and a (string) scalar [number of characters]. While there will never be any confusion on the part of Perl, it'll promote Thinking About Things The Wrong Way among Perl novices, who will try to think of strings as C-like arrays of characters. We've gone to great lengths to disabuse people of that notion in Perl5; let's keep it that way. Perhaps .size for number-of-elements and .length for length-of-string would work? Indeed, Larry mentioned a while back that C.length for arrays might be spelled C.elems or something, for that exact reason -- the term length is horribly ambiguous when you're using it on a scalar (string) value, when you've got Unicode (you need to be saying chars, or bytes, or elems, or whatever), and so maybe the word should change for arrays as well. Not sure what was decided on that particular one, if anything. We need to confirm. IIRC, C.length likely won't exist at all for strings. It still might exist (?) for arrays. MikeL
Re: Array Questions
Mark J. Reed [EMAIL PROTECTED] writes:
On 2003-01-07 at 11:31:13, Mr. Nobody wrote:
.length is unneeded, since an array gives its length in numeric context, so
you can just say +@a.
Unneeded, but harmless.
grep shouldn't be an array method either, it should be
like the perl5 grep, as it is often used on lists, grep /foo/, keys %h is
far more readable than @{[keys %h]}.grep(/foo/).
Didn't we already have the left-to-right vs. right-to-left discussion?
Regardless of how grep works when it's not invoked as a method, it
most definitely should be invokable as one on arrays. It would probably
be defined in a superclass rather than in Array itself, assuming Array
is a specific subclass of a more general collection class
(be it List or Collection or whatever), but that doesn't matter as long
as you can call it on an array.
Also, some of the line noise in your unreadable example comes from your
mixing method syntax with other syntax. No need to do all that @{[keys %h]}
stuff - it would just be %h.keys.grep(/foo/), which looks pretty darn readable
to me.
Or, even
%h.grep(- $pair {.key =~ /foo/})
depending on what you actually want (assuming that grep treats %h as a
list of pairs...)
Re: Array Questions
--- Deborah Ariel Pickett [EMAIL PROTECTED] wrote: Getting off topic here (a bit), but I think it's a Mistake to have .length mean different things on an array [Number of elements] and a (string) scalar [number of characters]. While there will never be any confusion on the part of Perl, it'll promote Thinking About Things The Wrong Way among Perl novices, who will try to think of strings as C-like arrays of characters. We've gone to great lengths to disabuse people of that notion in Perl5; let's keep it that way. Perhaps .size for number-of-elements and .length for length-of-string would work? sarcasm This would just cause them to Think About Things A Different But Equally Wrong Way: as assembly language objects whose SIZE in bytes is the determining component of their existence. /sarcasm Seriously, if they're smart enough to run a text editor, I think it's safe to say that they can handle the conceptual difference between the length (mins:secs) of a video, and the length (feet:inches) of the mag-tape that encodes the video. People deal with different inherent units all the time in the real world -- some of them even remember to carry the units through their equations when they're doing math. Let's give some credit to the audience at large. =Austin
Re: Array Questions
Perhaps .size for number-of-elements and .length for length-of-string would work? sarcasm This would just cause them to Think About Things A Different But Equally Wrong Way: as assembly language objects whose SIZE in bytes is the determining component of their existence. /sarcasm I am happy to see other suggestions for the names. The ones I mentioned were simply spur-of-the-moment ideas, which I agree have problems. Seriously, if they're smart enough to run a text editor, I think it's safe to say that they can handle the conceptual difference between the length (mins:secs) of a video, and the length (feet:inches) of the mag-tape that encodes the video. People deal with different inherent units all the time in the real world -- some of them even remember to carry the units through their equations when they're doing math. Let's give some credit to the audience at large. With respect, I have plenty of evidence to suggest that programming students *won't* handle the difference (many years of teaching first- and second-year programming at University). I see students at all levels saying things like: char *dupString = malloc(sizeof oldString + 1); when they mean: char *dupString = malloc(strlen(oldString) + 1); (Actually, that's a good argument against using size to mean number-of-elements of Perl arrays, isn't it?) Perhaps you are talking about experienced programmers rather than students. In that case, I agree with you. But everybody has to learn Perl once. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] Long and wide, eternity from side to side, lead me through the rapids, guide me to the shore. There's a place that's far beyond this time and space, when each of us comes face to face with something more. - _Siren Song_, Alan Parsons
Re: Array Questions
--- Deborah Ariel Pickett [EMAIL PROTECTED] wrote:
Seriously, if they're smart enough to run a text editor, I think
it's
safe to say that they can handle the conceptual difference between
the
length (mins:secs) of a video, and the length (feet:inches) of
the
mag-tape that encodes the video. People deal with different
inherent
units all the time in the real world -- some of them even remember
to
carry the units through their equations when they're doing math.
Let's
give some credit to the audience at large.
With respect, I have plenty of evidence to suggest that programming
students *won't* handle the difference (many years of teaching
first- and second-year programming at University). I see students at
all levels saying things like:
char *dupString = malloc(sizeof oldString + 1);
when they mean:
char *dupString = malloc(strlen(oldString) + 1);
(Actually, that's a good argument against using size to mean
number-of-elements of Perl arrays, isn't it?)
It's a good argument for better-explaining the difference between
pointer and target, not something that's likely to be a problem in
Perl.
One of the things I hated about HTML forms was that some things were
WIDTH= and some things were LENGTH= and some things were SIZE= and some
were COLS=. What crackhead smoked that up?
Much more consistent, readable, harmonious -- better -- to say
something like:
sub postoffice_sort(@items)
{
my @bins[10];
for (my $x = 0; my $x @items.length; $x++)
{
..
}
}
Re: Array Questions
--- Austin Hastings [EMAIL PROTECTED] wrote:
--- Deborah Ariel Pickett [EMAIL PROTECTED] wrote:
Seriously, if they're smart enough to run a text editor, I think
it's
safe to say that they can handle the conceptual difference
between
the
length (mins:secs) of a video, and the length (feet:inches)
of
the
mag-tape that encodes the video. People deal with different
inherent
units all the time in the real world -- some of them even
remember
to
carry the units through their equations when they're doing math.
Let's
give some credit to the audience at large.
With respect, I have plenty of evidence to suggest that programming
students *won't* handle the difference (many years of teaching
first- and second-year programming at University). I see students
at
all levels saying things like:
char *dupString = malloc(sizeof oldString + 1);
when they mean:
char *dupString = malloc(strlen(oldString) + 1);
(Actually, that's a good argument against using size to mean
number-of-elements of Perl arrays, isn't it?)
It's a good argument for better-explaining the difference between
pointer and target, not something that's likely to be a problem in
Perl.
One of the things I hated about HTML forms was that some things were
WIDTH= and some things were LENGTH= and some things were SIZE= and
some
were COLS=. What crackhead smoked that up?
Much more consistent, readable, harmonious -- better -- to say
something like:
sub postoffice_sort(@items)
{
my @bins[10];
for (my $x = 0; my $x @items.length; $x++)
{
..
}
}
Hit the post key too soon, there. Anyway, visualize an example
involving @items.length and $zipcode.length ...
=Austin
