[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.
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
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
"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
--- 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
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
[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 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:
> 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
[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.
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
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
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
--- 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
# 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]
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
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.
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 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
"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
--- 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
> > 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
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
# 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 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
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
--- 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
--- 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
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
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
>
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 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
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
33 matches
Mail list logo
