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 th
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 w
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
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 ac
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 sub-parts
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
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 pleas
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".
> >
> >
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 di
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 {
&g
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 $_) { ... }
> >
>
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 s
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 met
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
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
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 be
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 intente
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 eva
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
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.
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
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 o
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 y
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)
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
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
> 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 struc
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
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 conf
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 objec
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 non-o
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 t
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
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 po
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 is
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
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
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
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,
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
ted (immutable) list
-
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 wen
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 are
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 would
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
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, Mi
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) {
$dat
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
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
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 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 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 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
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
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 { ... }
-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
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
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 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
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 6
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
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
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
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
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
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 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)
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
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 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
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
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
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 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,
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 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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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/
Pe
> 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 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
1 - 100 of 259 matches
Mail list logo
