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
Applied, thanks.
Daniel Grunblatt.
On Sunday 05 January 2003 01:10, Jason Gloudon (via RT) wrote:
> # New Ticket Created by Jason Gloudon
> # Please include the string: [perl #19729]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display
On Tue, Jan 07, 2003 at 02:04:25PM -0800, Robert Spier wrote:
> At Tue, 07 Jan 2003 18:59:22 GMT,
> ([EMAIL PROTECTED]) (via RT) wrote:
> > # New Ticket Created by ([EMAIL PROTECTED])
> > # Please include the string: [perl #19800]
> > # in the subject line of all future correspondence about this
--- 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
# New Ticket Created by Jim Radford
# Please include the string: [perl #19807]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19807 >
I found a few typos while reading through the documentation in rx.ops.
-Jim
--- parrot-
> 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
At Tue, 07 Jan 2003 18:59:22 GMT,
([EMAIL PROTECTED]) (via RT) wrote:
> # New Ticket Created by ([EMAIL PROTECTED])
> # Please include the string: [perl #19800]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=19800 >
Sme
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
# New Ticket Created by ([EMAIL PROTECTED])
# Please include the string: [perl #19800]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19800 >
Below is the result of your feedback form. It was submitted by
[EMAIL PROTECTED]
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
Attached test program shows some additional effects of PMC size and
timing. [...]
Nifty.
The attached patch adds a scheme where:
- gc flags are in the pool, and
- pmc->pool mapping is done with aligned pools and pmc pointer masking.
Observations:
- It's fast. (The _test_ is anyway.) P
--- 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
Mitchell N Charity wrote:
The attached patch adds a scheme where:
- gc flags are in the pool, and
- pmc->pool mapping is done with aligned pools and pmc pointer masking.
Thanks for that.
Observations:
- It's fast. (The _test_ is anyway.) Perhaps 4x random, 10x+ linear.
I see ~8x/~1
[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.
33 matches
Mail list logo
