On 10/6/06, TSa [EMAIL PROTECTED] wrote:
HaloO,
Stevan Little wrote:
As for how the example in the OP might work, I would suspect that
super would not be what we are looking for here, but instead a
variant of next METHOD.
I'm not familiar with the next METHOD syntax. How does one get
On 10/6/06, TSa [EMAIL PROTECTED] wrote:
HaloO,
Stevan Little wrote:
On 10/2/06, Jonathan Lang [EMAIL PROTECTED] wrote:
This notion of exclusionary roles is an interesting one, though. I'd
like to hear about what kinds of situations would find this notion
useful; but for the moment, I'll
On 10/2/06, Brad Bowman [EMAIL PROTECTED] wrote:
Sam Vilain wrote:
TSa wrote:
is this subject not of interest? I just wanted to start a
discussion about the class composition process and how a
role designer can require the class to provide an equal
method and then augment it to achieve the
On 10/2/06, Jonathan Lang [EMAIL PROTECTED] wrote:
This notion of exclusionary roles is an interesting one, though. I'd
like to hear about what kinds of situations would find this notion
useful; but for the moment, I'll take your word that such situations
exist and go from there.
Well to be
Quick question for the group.
Can there be more than one authority?
module Foo-0.0.1-cpan:JRANDOM-http://www.foo.org-mailto:[EMAIL PROTECTED]
S11 would seem to indicate no (it states that names are made up of 3
parts), but I guess I am wondering if one of those parts can have
multiple
On 5/23/06, Sam Vilain [EMAIL PROTECTED] wrote:
Right, but we should really ship with at least a set of Meta Object
Protocol Roles, that covers the core requirements that we will need for
expressing the core types in terms of themselves;
- classes and roles
- attributes and methods
- subsets
On 3/5/06, Mark Overmeer [EMAIL PROTECTED] wrote:
* Stevan Little ([EMAIL PROTECTED]) [060305 02:49]:
On 3/4/06, Mark Overmeer [EMAIL PROTECTED] wrote:
Could we try to kind-of pre-register name-spaces for perl6 modules?
There is no need to do such a thing, we have the 3 level naming
On 3/4/06, Mark Overmeer [EMAIL PROTECTED] wrote:
One thing which is playing in my head already for some time is:
Do we really want a translation from Perl5 modules into Perl6 on
a one-to-one basis? There are so many deceased modules occupying
beautiful name-spaces! Can we please
On 3/2/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Can subs be declared within classes? Can methods be declared without
classes? If the answers to both of these questions are no, then it
occurs to me that you _could_ unify the two under a single name, using
the class boundary as the
On 3/2/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Stevan Little wrote:
Jonathan Lang wrote:
Can subs be declared within classes? Can methods be declared without
classes?
I would say yes.
Having subs inside classes makes creating small utility functions
easier. You could also
On 2/15/06, Rob Kinyon [EMAIL PROTECTED] wrote:
On 2/14/06, Stevan Little [EMAIL PROTECTED] wrote:
I think that the metaclass (stored in the pseudo-lexical $::CLASS)
should create a number of anonymous roles on the fly:
role {
multi method a (::CLASS $self
On 2/12/06, Yiyi Hu [EMAIL PROTECTED] wrote:
For perl 6,
Array and Scalar are in different namespace.
So,
class A { has $.a; has @.a };
what will A.new.a return by default?
An Error? or Scalar has a higher priority?
It seems to me that the best way to approach this issue is to seperate
On 2/12/06, Thomas Sandlass [EMAIL PROTECTED] wrote:
IIRC, you can always create a new method for a class, even outside of
its definition, simply by ensuring that the first parameter to be
passed in will be an object of that type:
method bark (Dog $_) { ... }
I don't think
On 2/8/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Stevan Little wrote:
Yes, that is correct, because:
Dog.isa(Dog) # true
$spot.isa(Dog) # true
^Dog.isa(Dog) # false
In fact ^Dog isa MetaClass (or Class whatever you want to call it).
At least that is how I see/understand
On 2/9/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Stevan Little wrote:
Jonathan Lang wrote:
OK. To help me get a better idea about what's going on here, what
sorts of attributes and methods would ^Dog have?
Well, a metaclass describes the behaviors and attributes of a class
On 2/8/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Consider my Dog $spot. From the Perl6-to-English Dictionary:
Dog: a dog.
$spot: the dog that is named Spot.
^Dog: the concept of a dog.
Am I understanding things correctly?
If so, here's what I'd expect: a dog can bark, or Spot can
On 2/7/06, Allison Randal [EMAIL PROTECTED] wrote:
On Feb 7, 2006, at 13:28, Yuval Kogman wrote:
Apologies if this is insulting to anyone, but personally I think
that Perl 6 (pugs, parrot, everything) is losing too much momentum
lately. I think we need to seriously rethink some of the
On 2/7/06, chromatic [EMAIL PROTECTED] wrote:
On Tuesday 07 February 2006 14:17, Yuval Kogman wrote:
De-facto we have people running PIL on javascript.
It works more than parrot does.
No, it works *differently* from Parrot, just as an LR parser works differently
from an LR parser.
Don't
On 2/7/06, Matt Fowles [EMAIL PROTECTED] wrote:
Stevan~
I am going to assume that you intended to reply to perl 6 language,
and thus will include your post in its entirety in my response.
Yes, sorry... I missed the reply to all button on the gmail UI by a
few pixels I guess. Thank you for
On 2/7/06, chromatic [EMAIL PROTECTED] wrote:
On Tuesday 07 February 2006 15:56, Stevan Little wrote:
The Pugs project and the Parrot project have had very different goals
actually (at least Pugs did from the early days). Pugs aimed to be
able to evaluate Perl 6 code, as a way of testing
On 2/7/06, Matt Fowles [EMAIL PROTECTED] wrote:
Stevan~
On 2/7/06, Stevan Little [EMAIL PROTECTED] wrote:
Well, to be totally honest, I think only Larry truely understands
their usage, but to the best of my understanding they are intented to
serve a number of roles;
I agree with you
On 2/7/06, Allison Randal [EMAIL PROTECTED] wrote:
On Feb 7, 2006, at 15:31, Stevan Little wrote:
Now I am not as involved in Parrot as I am in Pugs so I might be way
off base here, but from my point of view Parrot still has a long way
to go before it runs Perl 6 code. Part
Hello All,
Recently on #perl6 putter found the Slate language
(http://slate.tunes.org/) in our search for some information about
Smalltalk. Slate is a prototype based OO language which uses multi
method dispatch instead of more traditional method dispatch. As I
flipped through some of the papers
On 1/25/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Larry Wall wrote:
But my hunch is that it's
a deep tagmemic/metaphorical problem we're trying to solve here.
Such issues arise whenever you start making statements of the form
I want to use an A as if it were a B. The problem is much
On 1/26/06, Rob Kinyon [EMAIL PROTECTED] wrote:
On 1/26/06, Stevan Little [EMAIL PROTECTED] wrote:
Actually this might not be a bad approach in this case. Take this for
instance:
method foo (Foo $self, $key) {
((Hash) $self){$key}
}
The syntax is ugly, but it makes what you
On 1/26/06, Rob Kinyon [EMAIL PROTECTED] wrote:
On 1/26/06, Stevan Little [EMAIL PROTECTED] wrote:
If there is need to treat something as a Hash, then provide it with a
postcircumfix{} and leave it at that. It's highly unlikely that you
will want to add Hash-like behavior to something
On Thursday 19 January 2006 21:53, Stevan Little wrote:
With p5, you /can/ get to the underlying data structure. This is a
break which will hamper the backwards compatibility effort I think.
With Perl 5, you can *appear* to get to the underlying data structure. Yet
tie() is basically free
Larry Wall wrote:
On Fri, Jan 20, 2006 at 09:35:13PM +0800, Audrey Tang wrote:
My original intent was #2, hence the wording in A12. But to speak to
some of Stevan's concernes, there's something going on here which is
not quite Object does Hash. It's more like Object can do Hash,
in the
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
On Jan 19, 2006, at 5:09 PM, Juerd wrote:
Stevan Little skribis 2006-01-19 17:06 (-0500):
This turns everything is an object into everything can be used
with
OO syntax, which I think is more true
Alternatively and simultaneously, everything represents an object.
Well, if everything
On Jan 19, 2006, at 5:19 PM, Jonathan Scott Duff wrote:
On Thu, Jan 19, 2006 at 11:07:49PM +0100, Juerd wrote:
Stevan Little skribis 2006-01-19 16:59 (-0500):
2) what if the role conflicts with other roles being does-ed by Foo?
Debugging hell there.
Very good point.
Aren't role conflicts
On 1/19/06, chromatic [EMAIL PROTECTED] wrote:
Next question. If Ponie and Perl 6 are both running on Parrot, and
if Ponie
has PMCs that represent Perl 5 data containers, such as p5hash,
p5array,
p5symbol, and so on, what's the problem with having a Perl 6 object
that uses
one of those
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
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,
I hope everyone is having a good start to the new year.
As Audrey's posts have mentioned, we are starting to work on
container and boxed types in the PIL^N/PIL2 runcore. Over the
holidays I went through the most recent Synopsis and attempted to
compile a list of what I think
-
On Jan 3, 2006, at 6:15 PM, Stevan Little wrote:
Hello all,
I hope everyone is having a good start to the new year.
As Audrey's posts have mentioned, we are starting to work on
container and boxed types in the PIL^N/PIL2 runcore. Over the
holidays I went through the most recent Synopsis
Sorry, I tried to follow docs/submissions.pod, but my patch-fu is
very weak. Please forgive me.
This is a test for C3 MROs, it includes most of the tests from
Perl6::MetaModel prototype in Pugs (which themselves were stolen from
examples in Python and Dylan).
I am not sure where you
Michael,
You might want to look at some of the work on the Pugs test suite.
http://m19s28.vlinux.de/cgi-bin/pugs-smokeserv.pl
It uses (among other things) Test::TAP::Model and
Test::TAP::HTMLMatrix, and uses YAML as an intermediate test-run format.
Stevan
On Nov 22, 2005, at 2:11 PM,
Michael,
On Nov 22, 2005, at 3:13 PM, Michael Peters wrote:
Stevan Little wrote:
Michael,
You might want to look at some of the work on the Pugs test suite.
http://m19s28.vlinux.de/cgi-bin/pugs-smokeserv.pl
It uses (among other things) Test::TAP::Model and
Test::TAP::HTMLMatrix, and uses
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
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) {
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
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 { ... }
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
-level) code is then executed within the
context of the runtime (aka Object Space).
This is a very rough and high level view, and ignores little details
like macros, BEGIN blocks, etc.
Stevan
On Oct 23, 2005, at 12:29 PM, Stevan Little wrote:
Hello all,
So after reading fglock's Perl6
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
Hello all,
So after reading fglock's Perl6::Value/Container modules, some p6l
backtracing and some discussions on #perl6 with Luke and autrijus, I
have arrived at a very early (read: probably wrong) thoughts for the
p6 Object Space.
I see this step as critical in the development of Pugs
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 inheritable
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
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 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 more
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 .=
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
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
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
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
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
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
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
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
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
Cnew() class method wasn't inheritable.
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
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
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
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
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/
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 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
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
1 - 100 of 250 matches
Mail list logo
