Hello,
I'm working on a fix for https://github.com/rakudo/rakudo/issues/2250. While
the problem itself is easily tracks down to add_method not reporting a error,
the general fix requires clear understanding of what happens to submethods when
a role consumes another role. While thing
HaloO,
Luke Palmer wrote:
On 10/29/05, Damian Conway <[EMAIL PROTECTED]> wrote:
So we need a mechanism that is externally (i.e. from a class interface
point-of-view) a subroutine, but internally has the features of a method (i.e.
has an invocant). Since it's externally sub-like but internally
le that we could bring over the role idea of
> "required methods" and have the same basic principle relate to
> classes and submethods. If marked as such, a submethod is required to
> be implemented by a subclass, or class composition fails.
> I think that could be a useful fe
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> But factoring method implementations out into a subroutines is
DC> also extremely annoying, because a subroutine doesn't provide the
DC> internal conveniences that a method does. In particular, it
DC> doesn't have an invocant and
" and have the same basic principle relate to
classes and submethods. If marked as such, a submethod is required to
be implemented by a subclass, or class composition fails. I think
that could be a useful feature which would allow very safe re-use
along those lines.
Anyway, just my 2 cents.
Stevan
On 10/29/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> So we need a mechanism that is externally (i.e. from a class interface
> point-of-view) a subroutine, but internally has the features of a method (i.e.
> has an invocant). Since it's externally sub-like but internally method-like,
> we call th
In his use.perl.org journal, Luke wrote:
> To be fair, Damian responded to my query, but he didn't answer my
> question. He gave more an example of how submethods are used, rather
> than why they are used.
Subroutines are useful inside classes, for factoring class-specific
ILDALL and BUILD are not proper submethods yet
because Perl6::Object is not self defining yet. And it only supports
'P6opaque' right now, but I think I have the ordering of events
correct, however, please correct me if I am wrong.
Oh yeah, and all that silliness I wrote below,.. ignore it
On Wed, Jul 06, 2005 at 11:28:47AM -0400, Stevan Little wrote:
: It seemed to me from A12 that submethods are meant to define an
: interface of some kind, the BUILD/DESTROY submethods being the perfect
: example. However this means that BUILDALL and DESTROYALL need to be
: fairly magical. I say
On Wed, Jul 06, 2005 at 04:19:40PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Stevan Little wrote:
: >You seem to indicate that submethods are not to be used on instances,
: >and instead to be used on the underlying metaclass. I did not see
: >anything of the sort in (Syn|Apoc)1
Thomas,
On Jul 6, 2005, at 10:19 AM, TSa (Thomas Sandlaß) wrote:
S12 says in the section Submethods: "A submethod is called only when a
method call is dispatched directly to the current class."
And without finding a reference I think it was said that "the invocant
of a subme
Stevan Little wrote:
You seem to indicate that submethods are not to be used on instances,
and instead to be used on the underlying metaclass. I did not see
anything of the sort in (Syn|Apoc)12 or in my (limited) search of the
mailing list. Can you point me to that information?
S12 says in
Thomas,
On Jul 6, 2005, at 7:14 AM, TSa (Thomas Sandlaß) wrote:
One entry for &bar:(Foo) and one for &bar:(MetaClass[Foo])?
You seem to indicate that submethods are not to be used on instances,
and instead to be used on the underlying metaclass. I did not see
anything of the sort
Stevan Little wrote:
The concept of non-inherited infrastructural methods is fairly simple to
accomplish in the meta-model, by just giving submethods their own
dispatch table inside the metaclass. However where I am somewhat
confused is in how and when they get called.
I think the question
Again with the metamodel stuff :P
So, I am trying to implement the submethods correctly, and some
questions occurred to me.
The concept of non-inherited infrastructural methods is fairly simple
to accomplish in the meta-model, by just giving submethods their own
dispatch table inside the
On Mon, May 16, 2005 at 02:59:11PM +, Ingo Blechschmidt wrote:
: Hi,
:
: class Foo {
: submethod BUILD() {
: say 42;
: }
: }
:
: class Bar is Foo {
: submethod BUILD() {
: say 23;
: }
: }
:
: my Bar $bar .= new;
:
: I suppose this will o
Hi,
class Foo {
submethod BUILD() {
say 42;
}
}
class Bar is Foo {
submethod BUILD() {
say 23;
}
}
my Bar $bar .= new;
I suppose this will output:
42
23
S12 says that "submethod[s] [are] called only when a method call is
dispatched
17 matches
Mail list logo
