At 12:21 PM +0100 1/7/03, Rafael Garcia-Suarez wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Like I said, you can always use delegation to subclass an array,
or limit yourself to an odd and restrictive subset of behaviour.
(Basically just vtable method overriding)
Delegation has drawbacks c
On Jan-04, Leopold Toetsch wrote:
> Damian Conway wrote:
>
> >Piers Cawley wrote:
> >
> >>Acknowledgements
> >
> >But, of course, modesty forebade him from thanking the tireless Perl 6
> >summarizer himself, for his sterling efforts wading through the morasses
> >that are P6-language and P6-intern
On Mon, 6 Jan 2003, Michael Lazzaro wrote:
> So we're using "is Blah" here as a method of creating an
> already-instantiated object, not just typing a variable(?) But that,
> in turn, would imply that:
>
> my Foo $a; # declares $a as holding objects of type C
> my $a is Foo; # instan
On Tue, 7 Jan 2003, Dan Sugalski wrote:
>
> >2. There is a primitive "array" type that is promoted to an
> >objectified Array class when needed. This would be analogous
> >to the int/Int distinction for primitive numbers. This would be
> >visible to programmers, but may be acceptable for the same
>
At 9:47 AM -0800 1/6/03, Dave Whipp wrote:
"Piers Cawley" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Dan Sugalski <[EMAIL PROTECTED]> writes:
> An object is a data type, as much as an array or hash is a data type,
> but that doesn't make an array an objec
--- 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
--- 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 th
> > Perhaps .size for number-of-elements and .length for length-of-string
> > would work?
>
> 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.
>
I am happy to
--- 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 o
"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
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 Mi
> 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
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
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/, key
--- 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
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 fo
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 A
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Like I said, you can always use delegation to subclass an array,
> or limit yourself to an odd and restrictive subset of behaviour.
> (Basically just vtable method overriding)
Delegation has drawbacks compared to inheritance : you can't use
a object that
[EMAIL PROTECTED] (Simon Cozens) writes:
> they arrays?
Bluh, I mean objects. Getting carried away; this is something I do actually
care about, and I'll be quite unhappy if we screw it up.
--
The Blit is a nice terminal, but it runs emacs.
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Nothing, the impractical part is making arrays objects--they aren't,
Hang on. We're saying that they should be. You're saying that they're
not. You haven't produced any reasons *WHY* they're not. Why *aren't*
they arrays?
It's perfectly practical; most o
At 10:54 AM + 1/7/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
The short answer, I suppose, is that we're not recreating
Smalltalk--at least some small nod is being made towards Practicality.
I really don't follow your argument here.
What's impractical about being abl
[EMAIL PROTECTED] (Dan Sugalski) writes:
> The short answer, I suppose, is that we're not recreating
> Smalltalk--at least some small nod is being made towards Practicality.
I really don't follow your argument here.
What's impractical about being able to inherit from Arrays?
--
Familiarity bre
At 9:30 AM + 1/7/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
Well, you'll certainly be able to use delegation to get in the way if
nothing else. Beyond that I'm not sure, but anything that's not based
on the parrot Object PMC (which we've not quite yet defined) won't
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> These lines all declare @a to be an array that stores ints. That
> would imply that the "is Array" part is actually instantiating
> (Cing) the array... you're not saying that @a "can someday
> hold an array obj", you're saying it already _is_ an arr
"Piers Cawley" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> > An object is a data type, as much as an array or hash is a data type,
> > but that doesn't make an array an object. [insert obligatory "all men
> > are Soc
[EMAIL PROTECTED] (Dan Sugalski) writes:
> Well, you'll certainly be able to use delegation to get in the way if
> nothing else. Beyond that I'm not sure, but anything that's not based
> on the parrot Object PMC (which we've not quite yet defined) won't
> necessarily be directly inheritable from.
26 matches
Mail list logo
