Ovid <[EMAIL PROTECTED]> writes:
> --- Piers Cawley <[EMAIL PROTECTED]> wrote:
>>
>> How about:
>>
>> my method SCALAR::attributes($self:) { $$self }
>> my method HASH::attributes(%self:) { %self.kv }
>> my method ARRAY::attributes(@self:) { [EMAIL PROTECTED] }
>>
>> method _attributes(
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 h
All -
I'm partly to blame for this thread because I put the idea into
Steve's head that class methods being inheritable may be dogma and not
a useful thing. Mea culpa.
That said, I want to put forward a possible reason why you would
want class methods to be inheritable - to provide pure f
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.
For one example, look at my Cipher suite. (It's in Pugs's ext/Cipher
directory.) The
It was just kind of a pain because you
had to put a "=cut" after the "=end", and because you had to put
paragraph spaces between everything. We're getting rid of both of
those restrictions.
Excellent! That's what was really bugging me. I'm really glad that is
changing :)
Thanks,
Alfie
On 10/12/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> Plus, I can't imagine that a reverser for Parrot code is going to be that
> hard to
> write.
Disassembling register machine code is significantly more difficult
than disassembling stack machine code.
That said, if the level of introspective ca
Larry Wall wrote:
On Thu, Oct 13, 2005 at 09:43:15AM +1300, Sam Vilain wrote:
: Hi all,
:
: Is it intentional that S09 lists unboxed complex types, but equivalent
: Boxed types are missing from the "Types" section in S06?
Nope.
As it's a trivial omission, I went ahead and changed S06.pod (r6
On Thu, Oct 13, 2005 at 09:43:15AM +1300, Sam Vilain wrote:
: Hi all,
:
: Is it intentional that S09 lists unboxed complex types, but equivalent
: Boxed types are missing from the "Types" section in S06?
Nope.
Larry
On 10/12/05, chromatic <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-10-12 at 21:50 +0200, Yuval Kogman wrote:
>
> > This has even more implications with closed classes to which you
> > don't have source level access, and if this can happen it will
> > happen - i'm pretty sure that some commercial data
Hi all,
Is it intentional that S09 lists unboxed complex types, but equivalent
Boxed types are missing from the "Types" section in S06?
Sam.
On Wed, 2005-10-12 at 21:50 +0200, Yuval Kogman wrote:
> This has even more implications with closed classes to which you
> don't have source level access, and if this can happen it will
> happen - i'm pretty sure that some commercial database vendors would
> release closed source DBDs, for exampl
On Thu, Oct 13, 2005 at 05:42:31 +1000, Damian Conway wrote:
> Luke wrote:
>
> >Okay, I seriously have to see an example of a submethod in use.
>
> class Driver::Qualified {
> method drive {
> print "Brrrm brrrm!"
> }
> }
>
> class Driver::Disqualifi
Luke wrote:
Okay, I seriously have to see an example of a submethod in use.
class Driver::Qualified {
method drive {
print "Brrrm brrrm!"
}
}
class Driver::Disqualified is Driver {
submethod drive {
die .name(), " not allowed to driv
Actually, I wondered why you didn't suggest this earlier. :) I
figured you were a step ahead of me: What if I want more than a
boolean out of my class method?
On Oct 12, 2005, at 10:27, Stevan Little wrote:
Gordon,
It just occurred to me that the system shown below could be re-
written to
Okay, I seriously have to see an example of a submethod in use. BUILD
etc. don't count. Why? Because:
class Foo {
method BUILD () { say "foo" }
}
class Bar is Foo {
submethod BUILD () { say "bar" }
}
class Baz is Bar { }
Foo.new; # foo
Bar.new; #
On Wed, 2005-10-12 at 12:00 -0400, Stevan Little wrote:
> Usefulness aside, why do Roles and Classes need to be seperate
> beasts? In the current meta-model prototype, the role system is laid
> atop the class system so that the following is true:
>
> Class is an instance of Class
> Role is an
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 positional arguments
rather than named pairs (as the default does),
Hi,
TSa wrote:
> Ingo Blechschmidt wrote:
>> Exactly. I'd like to add that, under the proposal, you always know
>> what things are passed how, only by looking for a "*".
>>
>> foo $var;# always positionally, even if $var isa Pair
>> foo *$pair; # always named
>
> But where is the na
--- Piers Cawley <[EMAIL PROTECTED]> wrote:
>
> How about:
>
> my method SCALAR::attributes($self:) { $$self }
> my method HASH::attributes(%self:) { %self.kv }
> my method ARRAY::attributes(@self:) { [EMAIL PROTECTED] }
>
> method _attributes($attrs) {
> my @attributes = $attrs.attr
HaloO,
Ingo Blechschmidt wrote:
Exactly. I'd like to add that, under the proposal, you always know what
things are passed how, only by looking for a "*".
foo $var;# always positionally, even if $var isa Pair
foo *$pair; # always named
But where is the name? Is it 'pair'? Like in
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 positi
Gordon,
On Oct 12, 2005, at 10:48 AM, Gordon Henriksen wrote:
Actually, I wondered why you didn't suggest this earlier. :) I
figured you were a step ahead of me: What if I want more than a
boolean out of my class method?
Then you put the class methods back in :)
But then your Objective-C i
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 instead
Gordon,
It just occurred to me that the system shown below could be re-
written to do away with class methods entirely.
class Host {
my $.plugInClass;
}
role PlugIn {
method initWithHost (Host $h:) { ... }
}
role FeatureA {}
role FeatureB {}
role FeatureC {}
class AB {
does Plug
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
has an i
Alfie John skribis 2005-10-12 15:28 (+1000):
> Does Perl6 support multiline comments?
All incarnations of Perl have allowed us to begin multiple subsequent
lines with the comment glyph '#'. I am sure Perl 6 will not break this
tradition.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http:
Stevan Little <[EMAIL PROTECTED]> writes:
> 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
> (s
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 an invocant, as far as I'm concerned. (Method implies polymorph
29 matches
Mail list logo
