Abhijit Mahabal wrote:
When you dispatch, what happens would depend upon WALKMETH (according to
the pseudocode for CALLONE in A12). Usually the first inherited method
would get called.
Ohh, yes, that thing. I forget about it. And actually I hope that
there's a version among the standard pragmas t
David Storrs writes:
> On Mon, May 02, 2005 at 06:49:10PM +0200, Thomas Sandlaà wrote:
> > David Storrs wrote:
> > >class Tree {
> > > method bark() { die "Cannot instantiate a Tree--it is abstract!" }
> > >}
> > >class Birch {
> > > method bark() { return "White, papery" }
> > >}
> > >
On Mon, May 02, 2005 at 06:49:10PM +0200, Thomas Sandlaß wrote:
> David Storrs wrote:
> >Let's move this away from simple types like Str and Int for a moment.
>
> If you consider them simple...
When compared to
"arbitrary-class-that-was-defined-by-
arbitrary-programmer-of-
On Mon, 2 May 2005, [ISO-8859-1] Thomas Sandlaß wrote:
David Storrs wrote:
Tell me what this does:
class Tree { method bark() { die "Cannot instantiate a Tree--it is
abstract!" }
}
class Birch { method bark() { return "White, papery" }
}
class Oak { method bark() { return "Da
David Storrs wrote:
Let's move this away from simple types like Str and Int for a moment.
If you consider them simple...
Tell me what this does:
class Tree {
method bark() { die "Cannot instantiate a Tree--it is abstract!" }
}
class Birch {
method bark() { return "White, papery" }
}
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
> On Fri, 29 Apr 2005, Brent 'Dax' Royal-Gordon wrote:
>
> >David Storrs <[EMAIL PROTECTED]> wrote:
> >>Could we see some code that shows why this is a good idea? My initial
> >>reaction is horror; I can very easily see huge numbers
On Sun, May 01, 2005 at 10:59:59AM -0400, Aaron Sherman wrote:
> On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote:
> > Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > > On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
>
> > > > That would be absolutely horrible.
>
> You all s
On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
> > > That would be absolutely horrible.
> > Str|Int is simply the type of "Yes"|1, isn't it? That would certainly
> > make sig
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
> > On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
> > > I do not see how any auto-threading occurs in that code. It is completely
> > > innocuous in that sense, and I don't think th
On Sat, 30 Apr 2005, Aaron Sherman wrote:
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
I do not see how any auto-threading occurs in that code. It is completely
innocuous in that sense, and I don't think that is what horrif
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
> On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
> > I do not see how any auto-threading occurs in that code. It is completely
> > innocuous in that sense, and I don't think that is what horrified David.
> > What was troubl
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
> I do not see how any auto-threading occurs in that code. It is completely
> innocuous in that sense, and I don't think that is what horrified David.
> What was troublesome was, I think:
> my Str|Int $x;
> $x.foo(); # r
On Fri, 29 Apr 2005, Brent 'Dax' Royal-Gordon wrote:
David Storrs <[EMAIL PROTECTED]> wrote:
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
Could we see some code that shows
David Storrs <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
> > so we had junctions of Code references some days ago, what's with
> > junctions of Class and Role objects? :)
>
> Could we see some code that shows why this is a good idea? My initial
On Thu, Apr 28, 2005 at 03:28:41PM +0200, Ingo Blechschmidt wrote:
> so we had junctions of Code references some days ago, what's with
> junctions of Class and Role objects? :)
Could we see some code that shows why this is a good idea? My initial
reaction is horror; I can very easily see huge n
Aaron Sherman wrote:
Now, I'm not saying that that's the way it MUST be, just that that seems
to be the way that junctions would work in that situation.
I know, and I'm very confused about all these pseudo procedural uses
of junctions. And others seem to share my state of affairs.
If we decide
tha
On Thu, 2005-04-28 at 09:51, Thomas Sandlaß wrote:
> Ingo Blechschmidt wrote:
> > Hi,
> >
> > so we had junctions of Code references some days ago, what's with
> > junctions of Class and Role objects? :)
>
> I like them! In the type lattice A|B is the lub (lowest upper bound)
> of A and B. And A&
Ingo Blechschmidt wrote:
Hi,
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
I like them! In the type lattice A|B is the lub (lowest upper bound)
of A and B. And A&B is the glb (greatest lower bound) of A and B.
Both are cases of multiple in
Hi,
so we had junctions of Code references some days ago, what's with
junctions of Class and Role objects? :)
role A { method foo() { 42 } }
role B { method foo() { 23 } }
class Test does A|B {}
my Test $test .= new;
my $ret = $test.foo; # 42|23?
role A {}
role B { method foo()
19 matches
Mail list logo
