A long time ago ... Dan said:
Roles'll get thrown on individual variables and values, sure, but when
I'm writing a class (Yes, I know, but lets suspend disbelief for a
moment :) I'm not generally going to put a pre-existing role on a
class--I'll just inherit from the darned thing. Roles,
Hello all,
Autrijus asked me to look into the correct behavior for $pair.kv
yesterday, and I have been doing some spring cleaning of the Pugs test
suite, and found we actually have two conflicting tests for it. So I am
asking here to see what the official word is so that I can correct our
Hello all,
I have been going over the Synopsis, and I cannot find block labels
mentioned anywhere. I was under the impression that if it is not
mentioned, then it can be assumed to be the same as perl5. However, I
wonder if this is the case with labels given that everybody wants the
colon.
Hello All,
So I am expanding our .isa() tests for built-in datatypes (in
particular Array), and I have a few (probably very simple) questions
(since I cannot seem to find details on this anywhere).
Is there an isa() built-in for this?
Or it is really @array.meta.isa() (from the Introspection
Hello all.
In the processing of working with mugwump's shiny new perl6 OO Set.pm.
I realized that we do not currently have a way to uniquely identify
objects in Pugs like the way we have in perl5 (object stringification).
So I asked Autrijus, and he promptly implemented a rudimentary object
Juerd,
I would like an account too, username 'stevan' please.
On May 23, 2005, at 11:25 AM, Juerd wrote:
dev.pugscode.org seems indicated ...
Sorry, but 'dev' isn't cute enough :). And it's going to be
something.perl6.nl, probably. I don't mind aliases, though, but they
better be CNAMEs.
On May 25, 2005, at 5:39 AM, Piers Cawley wrote:
One of the 'mental apps' that's been pushing some of the things I've
been
asking for in Perl 6's introspection system is a combined
refactoring/debugging/editing environment for the language.
Maybe I have been reading too much about Smalltalk
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
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
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
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
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 means that BUILDALL
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?
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
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
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
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
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 {
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
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 submethods
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. So would it make
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
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
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
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
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 things as next
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
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
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
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
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
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' =
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
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 actual
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.
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
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
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
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.
1) Given this example, where 'bar' is a method stub (no implementation
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/
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
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-
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
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 polymorphically
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
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
has
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.
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 it, which
# the consuming class will get as a class method
method
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
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 system
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
methods.
Actually I
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.
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
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
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 made
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
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
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.
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
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
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
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 .=
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 collecting all
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
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 seems
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 to
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 you got
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
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'm really
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
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
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
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) {
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
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
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.
In
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 with Perl 5 code
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
On 1/18/06, chromatic [EMAIL PROTECTED] wrote:
On Wednesday 18 January 2006 18:54, Stevan Little wrote:
Or are you thinking that a Perl 6 value should be blessed into a
Perl
5 package?
That's closer to what I had in mind.
I think there is a real serious issue here since the hash the Perl
Hello,
I am forking this off the Perl 6 OO and bless thread since that
seems to have gotten bogged down in what it all means to Perl 5
interoperability. This was not really my intent with the original
thread, but I think it is still a fruitful discussion so I will re-
make my original
On Jan 19, 2006, at 4:10 PM, Rob Kinyon wrote:
Packages don't have anything to do with the class
system.
Actually ^Class.isa(^Package) ;)
Stevan
Juerd,
On Jan 19, 2006, at 4:10 PM, Juerd wrote:
Stevan Little skribis 2006-01-19 15:45 (-0500):
class Foo {
method new ($class: %params) {
$class.bless(%params);
Wouldn't that be %params.bless($class), or more directly,
%params.blessed = $class?
Nope, according to S12
Juerd,
On Jan 19, 2006, at 4:21 PM, Juerd wrote:
Juerd skribis 2006-01-19 22:18 (+0100):
Could you live with @foo being an array, and @foo in scalar context
returning a reference to that array? And with arrays being
interfaces to
underlying Arrays, which are objects, which makes arrays
1 - 100 of 130 matches
Mail list logo
