Hello,
As I am building the metamodel, I had a question, I did not find anything
specifically in
the docs regarding this.
What should I do when I encounter two attributes which can peacefully co-exist
as
attributes, but cause a class when we autogenerate the accessors for them. Here
is a
qu
Larry,
On Jul 5, 2005, at 9:08 PM, Larry Wall wrote:
If we pretend attribute declarations are anonymous role declarations,
they might
turn out to be just that, especially if we decide it's a useful
conceit.
This exact thing occurred to me as I was sitting in traffic on the way
back from $wor
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 met
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 in (Syn|Apo
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 submethod is a class obj
:)
Thanks,
Stevan
On Jul 6, 2005, at 1:45 PM, Larry Wall wrote:
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
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language, whose
favorite will be the default?
None
Ingo,
On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote:
Hi,
class Foo {}
class Bar is Foo {}
Bar.new.isa(Object);# true
Bar.new.isa(Class); # false
Bar.new.isa(Foo); # true
Bar.new.isa(Bar); # true
# These are clear, I think.
Yes, these all make sense to
Ingo,
On Jul 11, 2005, at 12:30 PM, Ingo Blechschmidt wrote:
I am not sure about this. I think that .isa as a class method should
behave much as it does for an instance method. If we start supporting
things like Bar.isa(Class) then we start exposing the soft underbelly
of the meta-model to the o
, Stevan Little wrote:
: Ingo,
:
: On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote:
: >Hi,
: >
: > class Foo {}
: > class Bar is Foo {}
: >
: > Bar.new.isa(Object);# true
: > Bar.new.isa(Class); # false
: > Bar.new.isa(Foo); # true
: > Bar.new.isa(Bar)
Ingo,
On Jul 11, 2005, at 3:14 PM, Ingo Blechschmidt wrote:
Hi,
Stevan Little wrote:
Actually I was thinking that MyClass.isa(...) would work much as it
did in Perl 5 (like an instance). But that access to the underlying
MyClass class instance would not be as simple. Something like
::MyClass
On Jul 11, 2005, at 3:07 PM, Larry Wall wrote:
Bar.meta.does(CLASS)# true
To me this is just code-reuse on the meta-level. Much like in smalltalk:
MetaClass isa
ClassDescription isa
Behavior isa
Object
and:
Class isa
Class
chromatic,
On Jul 11, 2005, at 4:26 PM, chromatic wrote:
On Mon, 2005-07-11 at 15:16 +0200, Ingo Blechschmidt wrote:
Bar.new.isa(Object);# true
Bar.new.isa(Class); # false
Bar.new.isa(Foo); # true
Bar.new.isa(Bar); # true
I'd like to go on a tangent to suggest tha
Hello,
More questions for the metamodel. I am trying to add proper submethod
and private method handling and I have a question about method
resolution order as a whole. I asked a similar question last week, but
this time I have more details :)
Given this class:
class Foo {
submethod
Larry,
On Jul 13, 2005, at 2:30 PM, Larry Wall wrote:
: The Syn/Apoc seem to indicate that methods and submethods of the same
: name can coexist. So the class definition itself is legal. However,
it
: brings up an issue when it comes time to call bar().
If the Syn/Apoc is giving that impressi
Larry,
Thanks for the detailed reply. Just a few more questions and I think I
can get this into the metamodel :)
On Jul 14, 2005, at 3:40 PM, Larry Wall wrote:
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of "current class" for
Larry,
Thanks much, this all makes sense. :)
Thanks,
Stevan
On Jul 14, 2005, at 4:54 PM, Larry Wall wrote:
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: Now, the metamodel currently does not have MMD, and I think "next
: METHOD" is not as relevant in SMD. S
@Larry,
I have been reading up on method resolution orders and class precedence
lists and all sort of meta-model esoteria. Which brings me to ask
myself, "How should all this be done in Perl 6?".
The current state of the prototype meta-model is that it only supports
pre-order class traversal
Larry,
On Jul 18, 2005, at 3:21 PM, Larry Wall wrote:
On Mon, Jul 18, 2005 at 02:54:40PM -0400, Stevan Little wrote:
: Ok, I will un-warnock myself here :)
Sorry, I've been occupied by various time-consuming family obligations.
My own fault, I asked on the weekend. People *should* spend
Ok, I will un-warnock myself here :)
As of r5674 in the Pugs tree, the Perl6::MetaModel now supports all the
A12 dispatch orders.
:canonical # canonical dispatch order
:ascendant # most-derived first, like destruction order
:descendant # least-derived first, like con
Larry,
This means that Roles are now first-class-ish things. Meaning they
cannot just simply be composed into classes since now we have to keep a
table of elements which are private to a Role.
I personally don't like this, I think it brings us back to Mix-ins and
(possibly) looses some of th
Larry,
On Jul 21, 2005, at 8:07 PM, Larry Wall wrote:
On Thu, Jul 21, 2005 at 05:15:34PM -0400, Stevan Little wrote:
: This means that Roles are now first-class-ish things. Meaning they
: cannot just simply be composed into classes since now we have to
keep a
: table of elements which are
Brent,
On Jul 22, 2005, at 3:53 AM, Brent 'Dax' Royal-Gordon wrote:
(If not this, I at least would like to see a way to make roles and/or
class extensions optionally merge their namespace with the class
they're being composed into; a simple 'is merged' on the
role/extension's definition might do
On Jul 24, 2005, at 2:40 AM, Sam Vilain wrote:
Stevan Little wrote:
Yes, we have. One thing to consider is that it is much easier to get
the "Role order doesn't matter" thing when they are composed. Once
you start keeping the roles around, you run into the possiblity for
such
Hello All,
Since autrijus is now busy porting the P5 metamodel prototype into
Haskell for use in Pugs, I have decided to begin work on documenting
the Perl6::MetaModel prototype modules more thoroughly. The first step
I see in this is to define a Meta Object Protocol (aka - the stuff you
can
Mark,
On Aug 8, 2005, at 4:26 PM, Mark Reed wrote:
Coming in late here, but it seems odd to have an actual class called
"MetaClass". The meta-object protocols with which I am familiar have
the
concept of a metaclass (a class whose instances are themselves
classes), and
the class Class is su
objects be the invocants for class methods, and
the MetaClass objects be the invocants for the methods defined by the
meta-object protocol, we are avoiding any namespace clashes.
Anyway, just wanted to add that :)
- Stevan
On Aug 8, 2005, at 5:49 PM, Stevan Little wrote:
Mark,
On Aug 8, 2005
Guten Tag Herr Sandlaß,
On Aug 9, 2005, at 4:48 AM, TSa (Thomas Sandlaß) wrote:
HaloO,
Stevan Little wrote:
Here is a 10,000 ft view of the metamodel prototype I sketched out
the other day
(http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/docs/
10_000_ft_view.pod). It should shed a
Stuart,
On Aug 9, 2005, at 9:25 AM, Stuart Cook wrote:
Stevan,
Up until today, I thought I had a good idea of how your metamodel
works, but now I'm confused. My main sticking point is that a class
Foo seems to have three different aspects:
Foo
class(Foo)
meta(Foo)
For each of these, could yo
On Aug 9, 2005, at 12:36 PM, TSa wrote:
HaloO Stevan,
you wrote:
Guten Tag Herr Sandlaß,
you know that a formal German greeting in a collequial
environment can be interpreted as unfriendly? I don't
do that but just wanted to state the fact.
My apologies, no unfriendliness intended :)
The
On Aug 9, 2005, at 10:52 AM, TSa wrote:
~ Foo ~
Is a type that variables etc. can be declared to have
Is not an object
=> I'm really not sure about this...
Bare Foo is a namespace lookup.
Yes, TSa is right. Everything below this is Type-stuff and I will leave
that to him (up until the Met
Howdy,
I wanted to make sure this question had a chance to get addressed, so I
am seperating it from the other thread which has digressed into the
depths of the metamodel (much to my delight too).
So..., as described in the other thread, the following statements are
true about the metamodel.
More MOP related questions :)
In the p5 MetaModel, you can do the following:
$obj->meta->add_method('foo' =>
Perl6::Method->create_instance_method(sub { ... }));
$obj->meta->add_method('foo' => Perl6::Method->create_class_method(sub
{ ... }));
$obj->meta->add_method('foo' => Perl6::Method->cre
Larry,
On Aug 9, 2005, at 6:18 PM, Larry Wall wrote:
: Personally I am not a fan of the 'is_a' name, I just did it one day,
: and it sort of stuck.
Well, hey, I'm not a fan of the "isa" name, so I guess we're even.
fair enough :)
: But I do think we need to find a way to
: differentiate bet
Larry,
On Aug 9, 2005, at 7:19 PM, Larry Wall wrote:
: >So far, this is what I have picked up; some/most of it is probably
: >wrong:
: >
: >~ Foo ~
: >Is a type that variables etc. can be declared to have
:
: That is one way to look at it I suppose. The reality is that there
will
: be no actua
Hello all,
I tried to search for this answer in AES12, but I did not see anything,
and a perl6.lang search just brought up the whole $_.method vs.
./method debate (which was too much to shlog through).
So, onto my question, I am wondering what are the valid scopes for
$?SELF and $?CLASS.
A
On Aug 17, 2005, at 2:28 PM, Ingo Blechschmidt wrote:
Hi,
Stevan Little wrote:
So, onto my question, I am wondering what are the valid scopes for
$?SELF and $?CLASS.
Are these (magical) globals who only have bound values in certain
contexts? If that is so, what value do they have outside of
Larry,
On Aug 17, 2005, at 2:53 PM, Larry Wall wrote:
: As for submethods, I see them like this:
:
: submethod foo () { ... }
:
: is really ..
:
: submethod foo () {
: next METHOD unless $?SELF ~~ $?CLASS;
: }
:
: At least that is how larry explained to me about a month ago.
Can't use ~~
Hey all,
I recently added Package and Module into the MetaModel (2.0) so that
Package is an Object
Module is a Package
Class is a Module
as mentioned here
http://article.gmane.org/gmane.comp.lang.perl.perl6.language/4599.
Currently Packages have names and Modules add version and auth
Larry,
On Sep 7, 2005, at 11:46 AM, Larry Wall wrote:
: I base this off the AUTO* hooks described in
: S10. I assume too that the METH slot is only valid for Classes, and
not
: appropriate for Packages and Modules.
All those entries are based on the notion of intuiting from the first
characte
Larry,
On Sep 7, 2005, at 12:45 PM, Larry Wall wrote:
: >All sigils and twigils are part of the key to the symbol table, so
it's
: >now just
: >
: >Foo<$.baz>
:
: What would Foo<$.baz> return though (assuming Foo is a class)? It
: cannot return a value since it is an instance specific value
Larry,
On Sep 8, 2005, at 2:30 PM, Larry Wall wrote:
On Wed, Sep 07, 2005 at 03:00:29PM -0400, Stevan Little wrote:
: Also, is there anyway to iterate over the keys in the namespace? The
: old way would be to do something like keys(%Foo::). Is something like
: this possible with the new way
Larry,
On Sep 8, 2005, at 5:07 PM, Larry Wall wrote:
On Thu, Sep 08, 2005 at 04:52:52PM -0400, Stevan Little wrote:
: But what if I want to do this?
:
: class Foo {
: my %:stuff;
: method keys (Class $c:) {
: %:stuff.keys();
: }
: }
:
: How can I get at my
Hello all.
I have some questions about how Roles will behave in certain
instances, and when/where/what $?ROLE should be bound too.
1) Given this example, where 'bar' is a method stub (no implementation)
role Foo {
method bar { ... }
}
Should the eventually implemented method still have
> From: Luke Palmer <[EMAIL PROTECTED]>
>On 9/11/05, Stevan Little <[EMAIL PROTECTED]> wrote:
>> Hello all.
>>
>> I have some questions about how Roles will behave in certain
>> instances, and when/where/what $?ROLE should be bound too.
>>
>&g
Hello again.
In my never ending quest to implement the Perl 6 object model, I have
started drawing pictures. Here is the latest version:
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
p6_object_model.jpg
(and for OmniGraffle users: http://svn.openfoundry.org/pugs/perl5/
Pe
On Sep 12, 2005, at 3:56 PM, Nathan Gray wrote:
Yep, someone needs to make a diagram about Roles, too.
Here yah go.
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
p6_role_model.jpg
I am planning on making Roles self-bootstrapping, so the class(Role)
will actually be the
Nathan,
On Sep 21, 2005, at 9:02 AM, Nathan Gray wrote:
On Tue, Sep 20, 2005 at 08:16:23PM -0400, Stevan Little wrote:
http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel2.0/docs/
p6_role_model.jpg
I am planning on making Roles self-bootstrapping, so the class(Role)
will actually be the
Evening all,
So I am in the process of adding class-methods into the meta-model
using eigenclasses. Eigenclasses are a ruby thing (and also a CLOS
thing IIRC), in which an anon-class is inserted between an instance
and it's class, essentially replacing the instance's class. The anon-
class
Luke,
On Oct 10, 2005, at 7:47 PM, Luke Palmer wrote:
How do you explain this:
class Foo {
method bar (Class $class:) { "class method" }
}
say Foo.bar;# class method
my $foo = Foo.new;
say $foo.bar; # class method
Assuming that that is valid Perl.
It
Hello all.
I would like to propose that class methods do not get inherited along
normal class lines.
I think that inheriting class methods will, in many cases, not DWIM.
This is largely because your are inheriting behavior, and not state
(since class attributes are not inheritable). Let m
Damian,
On Oct 11, 2005, at 6:53 PM, Damian Conway wrote:
Anyway, I have said my peace, what do you all think?
I think there are serious problems with this proposal. For a start,
it would be very difficult to create *any* objects at all if the
C class method wasn't inheritable.
Actually
David,
On Oct 11, 2005, at 7:49 PM, Dave Whipp wrote:
Stevan Little wrote:
I would like to propose that class methods do not get inherited
along normal class lines.
One of the things that has annoyed me with Java is that it's class
methods don't inherit (dispatch polymorphica
David,
On Oct 11, 2005, at 8:42 PM, Dave Whipp wrote:
Stevan Little wrote:
David,
...
If you would please give a real-world-useful example of this usage
of class-methods, I am sure I could show you, what I believe, is
a better approach that does not use class methods.
...
The
Gordon,
On Oct 11, 2005, at 9:10 PM, Gordon Henriksen wrote:
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
You mean, make them *not methods?* Because it's not a method unless it
h
Piers,
On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote:
We definitely have two instances of A since, B.isa(::A). We also have
a fragile implementation of count.
:)
Sorry, I purposefully made it a kludge as that is usually the way the
example is shown in most tutorials about class methods.
y.org/pugs/perl5/Perl6-MetaModel/t/
38_PlugIn_example.t
Stevan
On Oct 12, 2005, at 9:41 AM, Stevan Little wrote:
class Host {
my $.plugInClass;
}
role PlugIn {
method initWithHost (Host $h:) { ... }
}
role SupportsFeatureA {
# yes, this Role has a "class method" in
Larry,
On Oct 11, 2005, at 8:47 PM, Larry Wall wrote:
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
: Hello all.
:
: I would like to propose that class methods do not get inherited
along
: normal class lines.
I think most class methods should be written as submethods
ive-C interface would need to change too.
Although, the more complexity you introduce, the closer you get to
the point when a Factory pattern is just as viable an approach as
class methods.
Stevan
On Oct 12, 2005, at 10:27, Stevan Little wrote:
Gordon,
It just occurred to me that the s
Gordon,
On Oct 12, 2005, at 11:04 AM, Gordon Henriksen wrote:
On Oct 12, 2005, at 09:41, Stevan Little wrote:
If you use the BUILD submethod, then you never need to worry about
a that, everything is initialized for you by BUILDALL. Now, if you
want to have a constructor which accepts
Brent,
On Oct 11, 2005, at 8:17 PM, Brent 'Dax' Royal-Gordon wrote:
Stevan Little <[EMAIL PROTECTED]> wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
I think you're not thinking about many major usage cases for class
On Oct 13, 2005, at 9:47 AM, Matt Fowles wrote:
On 10/13/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases
On Oct 13, 2005, at 4:45 PM, TSa wrote:
No, not that class has no state, but that with the currently
specced classes we have inherited behaviors (class methods) but
they do not inherit the accompanying state (class attributes) as
well. I see this as potentially very problematic.
What
Well, I suspected there would not be much support for my initial
proposal on class methods, but I felt I had to try. Not being the
type of person who gives up easily, I want to revise the proposal
(incorporating some of the ideas in the responses).
I propose that class methods are inheritab
Hey All,
So, given the abundance of positive responses ;) for my "class
methods don't inherit" proposal, I have decided to withdraw that
proposal (see my last response on the thread). Of course, this means
we now have to work out the details of exactly *how* they get
inherited in all situ
Piers,
On Oct 14, 2005, at 12:14 PM, Piers Cawley wrote:
Stevan Little <[EMAIL PROTECTED]> writes:
On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote:
We definitely have two instances of A since, B.isa(::A). We also
have
a fragile implementation of count.
:)
Sorry, I purposefully mad
Larry,
On Oct 14, 2005, at 1:28 PM, Larry Wall wrote:
Generics are somewhat orthogonal to the mutable/immutable distinction,
except that they're a better fit for roles because someone has to
choose when to instantiate them, and they're easier to understand
with early binding rather than late bin
Larry,
I have been giving a lot of thought to the way you have been
describing classes lately. I think I understand where you are going
with it, but I need to understand some of the details.
On Oct 14, 2005, at 2:15 PM, Larry Wall wrote:
This only reinforces my view that all the meta stuff
Larry,
On Oct 14, 2005, at 2:15 PM, Larry Wall wrote:
Look guys, I want it to just consistently be
method bark (Dog $d) {...}
regardless of how instantiated the dog is. Think of partially
instantiated subroutines via .assuming. A sub is a sub regardless of
how much it's been curried. So
Larry,
On Oct 15, 2005, at 11:25 AM, Larry Wall wrote:
: >But we have to think a bit more about the notion of currying class
: >objects into real objects, or something approaching real objects.
:
: This is an interesting thought, I will have to ponder it some,
but it
: has a nice smell. Of co
Larry,
On Oct 15, 2005, at 11:25 AM, Larry Wall wrote:
On Sat, Oct 15, 2005 at 10:34:34AM -0400, Stevan Little wrote:
: I think what bothers me most about this is that it seems there is no
: way to tell the difference between class methods and instance
: methods. That the distinction is only
Miroslav
On Oct 17, 2005, at 7:35 AM, Miroslav Silovic wrote:
[EMAIL PROTECTED] wrote:
I think what bothers me most about this is that it seems there is
no way to tell the difference between class methods and instance
methods. That the distinction is only made when the body of the
metho
On Oct 17, 2005, at 12:32 PM, TSa wrote:
This also means that they would not (directly) be inheritable
since inheritence moves along superclass lines, and not with
@ISA. I am also not sure what you mean about multi-methods
either, could you please explain more?
Symmetric MMD at least h
Uri,
Well, aside from what is actually *in* Perl 6 currently, there are a
number of interesting side projects, which may or may not get
included in the final language design. Such as:
On Oct 18, 2005, at 3:40 AM, Uri Guttman wrote:
the new OO design (stole the best from the rest and pe
On Oct 18, 2005, at 6:56 AM, Miroslav Silovic wrote:
Disclaimer: I don't ~~ @larry :)
[EMAIL PROTECTED] wrote:
class Bar {
our $.bar;
{
my $.foo;
}
}
I assume that the leading "$." is what makes the difference,
however, IIRC the "$." is just part of the name, and no mor
On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote:
On 10/18/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
3) Macros. Nuff said.
Not quite. Lispish macros, that is, macros that let you look at what
you're expanding.
To further expand on this, they will be AST-manipulating macros (LISP
style)
Nicholas,
This is addressed in S11, here is a link:
http://search.cpan.org/~ingy/Perl6-Bible/lib/Perl6/Bible/S11.pod
To summarize, the syntax to load the modules is:
use Dog-1.2.1;
While the syntax to create a specific version of a module is:
my Dog-1.3.4-cpan:JRANDOM $spot .= new("woo
On Oct 18, 2005, at 11:15 PM, Rob Kinyon wrote:
NB: Dog-*-cpan:LWALL and Dog-*-cpan:JRANDOM, as well as *-*-cpan:LWALL
are also needed for entry into the mix because if there's only one
module loaded that is signed by cpan:LWALL, that should be sufficient
disambiguation for the parser. (How main
Larry,
On Oct 19, 2005, at 4:10 AM, Larry Wall wrote:
On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote:
: Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol
: table. Then once the compilation process is complete, I traverse the
: symbol table hierarchy coll
Just an FYI to anyone who is interested.
I have implemented the basic Eigenclass structure into the most
recent meta-model prototype. It basically looks like this:
Class
^
:
eFoo<...eBar
^ ^
| |
Foo<...Bar
This allows for completely inheritabl
Hey all,
I was messing around with GraphViz today and wrote a quick hack to
autogenerate class diagrams using the reflective capabilities of the
metamodel prototype. I put some of the more interesting diagrams
online, you can view them here:
http://perlcabal.org/~stevan/mm_viz/index.html
Darren,
Your problem reminds me of the "Expression Problem", which is
something that IIRC Luke's Theory idea was trying to solve. Here is
the link to a paper Luke referred me to on the subject:
http://scala.epfl.ch/docu/files/IC_TECH_REPORT_200433.pdf
Also, you can Google the phrase "Expre
On Oct 25, 2005, at 6:31 AM, Michele Dondi wrote:
On Fri, 14 Oct 2005, Stevan Little wrote:
I think Perl 6's OO system has the potential to be to OO
programming what Perl 5, etc was to text processing. This, I
believe, is in large part due to
Sorry for replying so late. Thought it
Larry,
On Oct 25, 2005, at 4:37 PM, Larry Wall wrote:
On Mon, Oct 24, 2005 at 06:33:20AM -0700, Ashley Winters wrote:
: # behavior through prototype -- guessing realistic syntax
: Base.meta.add_method(
: do_it => method ($arg) {
: say "doing $arg!";
: });
:
:
: # or, just add it
On Oct 26, 2005, at 12:05 PM, Larry Wall wrote:
Of course, there are other words that are somewhat synonymous with
"class", Unfortunately "sort" is already hosed. Maybe "kind".
Actually "kind" is used in the "Core Calculus for Metaclasses" paper
which I brought to the hackathon (not sure if
Hello all,
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
method foo { ... }
method bar { ... } # we will use this later :)
}
role Bar {
method foo { ... }
Yuval,
On Oct 28, 2005, at 10:59 AM, Yuval Kogman wrote:
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
Now, at this point we have a method conflict in suspension since
(according to A/S-12) method conflicts do
not throw an error until a role is composed into a class. This
On Oct 28, 2005, at 11:17 AM, Jonathan Scott Duff wrote:
On Thu, Oct 27, 2005 at 10:19:16PM -0400, Stevan Little wrote:
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.
Here is the basic issue:
role Foo
On Oct 28, 2005, at 11:38 AM, Jonathan Scott Duff wrote:
On Fri, Oct 28, 2005 at 04:59:18PM +0200, Yuval Kogman wrote:
If, OTOH we have a diamond inheritence:
You mean composition. There is no "role inheritance" :)
role A { method foo { ... } }
role B does A {};
role C does A
On Oct 28, 2005, at 2:54 PM, Jonathan Scott Duff wrote:
On Fri, Oct 28, 2005 at 02:29:36PM -0400, Stevan Little wrote:
I should be allowed to create a role with all sorts of conflicts
which
I leave for the classes to deal with.
Er, why? I've read this sentence several times and I
On Oct 28, 2005, at 3:04 PM, Jonathan Scott Duff wrote:
But, I'm probably wrong about this as the X role may have methods that
use $:foo in one way and the Y role may have methods that use $:foo in
some other, incompatible way, so perhaps there will be a conflict just
as when there are 2 methods
On Oct 28, 2005, at 3:45 PM, Rob Kinyon wrote:
Doing it any other way leads to the following: if A does rA and B isa
A and B defines an attribute that conflicts with the one provided by
rA, how on earth is that supposed to be detected? Especially given
that the inheritance tree of a class can be
Luke,
On Oct 28, 2005, at 9:44 PM, Luke Palmer wrote:
It was the fact that at each stage of the game, we summarized the
defaults and requirements for each role, ignoring the internal makeup
(i.e., what roles were composed into it, etc.).
This then imposes somewhat of an ordering with role comp
Luke,
On Oct 29, 2005, at 3:42 PM, Luke Palmer wrote:
Another thing that scares me with the "utility sub" point of view
follows:
class Foo {
method process_data($data) {
$.help_process_data($data);
}
submethod help_process_data($data) {
$dat
On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method
Hello all,
I have been reading the recently updated Synopsis 12, and a few
things jumped out at me. In the "Classes" section, classes are
described like this:
Classes are primarily for instance management, not code reuse.
Later in the same section the following is stated:
Every cl
Hello again,
In Pugs, we are currently trying to figure out how classes are
initialized with $repr types other than P6opaque. My interpretation
of S12 is that P6opaque types are initialized as follows (by default):
&new is called with named arguments, it then calls &bless passing in
'P6op
Hello All,
In reading over the Synopsis again in hopes of finding more
information regarding the different repr types (see the warnocked
post entitled "Construction and Initialization of repr types other
than P6opaque"), I stumbled onto some issues with the Perl 6 OO model
and &bless.
I
On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 18 January 2006 14:13, Stevan Little wrote:
Do we really still need to retain the old Perl 5 version of &bless?
What purpose does it serve that p6opaque does not do in a better/
faster/cleaner way?
Interoperability w
On Jan 18, 2006, at 10:41 PM, Trey Harris wrote:
Excuse my ignorance of the finer points, but I thought the reason
for bless's continued existence was so that the same sort of
brilliant OO experimentation that Damian and others have done with
pure Perl 5 can continue to be done in pure Perl
1 - 100 of 145 matches
Mail list logo
