Leopold Toetsch wrote:
Good. Now Evil Leo (who can't program in Python ;) writes some piece of
code like this:
$ cat m.py
class M(type):
def __new__(meta, name, base, vars):
cls = type.__new__(meta, name, base, vars)
cls.__add__ = myadd
return cls
def myadd(self, r):
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Ah! Now we are getting somewhere!
Yeah. That's the goal.
> So, why have I proceeded in this manner? Two reasons.
Fair enough, both.
>> So given that we have a set of language-neutral PMCs in core that do the
>> right thing, Python or Perl PMCs can inherit
Ah! Now we are getting somewhere!
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
So *all* lookups (complete with the asterisks) does not mean *all* lookups.
How about ?
Let's first concentrate on simpler stuff like infix operators.
OK, but the point is that the
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> So *all* lookups (complete with the asterisks) does not mean *all* lookups.
> How about ?
Let's first concentrate on simpler stuff like infix operators.
>> Citing S06: "Operators are just subroutines with special names."
> That sta
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
Another good reason to use pmc->vtable->fine_method in *all* lookups. So
the PMC has full control over the dispatch.
How does one lookup the C method? That will remain a
VTABLE, entry right?
Yes of course.
So *all*
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Another good reason to use pmc->vtable->fine_method in *all* lookups. So
>> the PMC has full control over the dispatch.
> How does one lookup the C method? That will remain a
> VTABLE, entry right?
Yes of course.
> All *external*
Leopold Toetsch wrote:
The current delegation internals are not likely a good match for
languages like Python or Ruby. I see such languages as implementing
their own semantics for classes, and Parrot limiting its knowledge to
methods like findmeth and invoke.
Another good reason to use pmc->vtabl
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> There is of course a test case. I have mentioned it at least 20 times ;)
>> t/op/gc_13.imc - currently using lexicals.
> $ parrot t/op/gc_13.imc
> 3 * 5 == 15!
> What's broken?
By using lexicals it works now.
> The current delegat
Leopold Toetsch writes:
>
> On a semi-related note, can I get a classoffset without doing a hash
> lookup? That is, can I store the class number I get assigned somewhere
> for quick fetching?
Hey now, you're citing the Luke Palmer that writes code. Don't confuse
him with the Luke Palmer who doe
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
My philosophy is simple: things without test cases tend not not get
fixed, and when fixed, tend not to stay fixed.
There is of course a test case. I have mentioned it at least 20 times ;)
t/op/gc_13.imc - currently u
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> My philosophy is simple: things without test cases tend not not get
> fixed, and when fixed, tend not to stay fixed.
There is of course a test case. I have mentioned it at least 20 times ;)
t/op/gc_13.imc - currently using lexicals.
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
"correct". I've discovered and analysed the problem with continuations.
I've made a proposal to fix that. No one has said that it's technically
wrong or couldn't work. It seems you are liking the idea, but Dan
doesn't
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>
>> "correct". I've discovered and analysed the problem with continuations.
>> I've made a proposal to fix that. No one has said that it's technically
>> wrong or couldn't work. It seems you are liking the idea, but Dan
>> doesn't. Now
Ashley Winters wrote:
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote:
Leopold Toetsch writes:
This term came up in a recent discussion[1]. But I'd like to give this
term a second meaning.
Except what you're talking about here is premature *optimzation*.
You're expecting ce
Leopold Toetsch wrote:
"correct". I've discovered and analysed the problem with continuations.
I've made a proposal to fix that. No one has said that it's technically
wrong or couldn't work. It seems you are liking the idea, but Dan
doesn't. Now what?
I would suggest focusing on one issue at a time
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>> This term came up in a recent discussion[1]. But I'd like to give this
>> term a second meaning.
> Except what you're talking about here is premature *optimzation*.
No. I don't think so.
>> During design considerations we (inclu
can you unsubscribe me asap
rgds
venkat
-Original Message-
From: Ashley Winters [mailto:[EMAIL PROTECTED]
Sent: Monday, December 06, 2004 7:19 AM
To: Luke Palmer
Cc: Leopold Toetsch; Perl 6 Internals
Subject: Re: Premature pessimization
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
> > This term came up in a recent discussion[1]. But I'd like to give this
> > term a second meaning.
>
> Except what you're talking about here is premature *optimzation*.
> You're expecting certain
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
> > This term came up in a recent discussion[1]. But I'd like to give this
> > term a second meaning.
>
> Except what you're talking about here is premature *optimzation*.
Yes, indeed.
Cheers,
Mich
Leopold Toetsch writes:
> This term came up in a recent discussion[1]. But I'd like to give this
> term a second meaning.
Except what you're talking about here is premature *optimzation*.
You're expecting certain forms of the opcodes to be slow (that's the
pessimization part), but then you're acut
20 matches
Mail list logo
