Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-27 Thread Rob Kinyon
On 10/27/05, Larry Wall <[EMAIL PROTECTED]> wrote: > On Thu, Oct 27, 2005 at 05:37:13AM -0400, Rob Kinyon wrote: > : Will I be able to do something like: > : > : package Foo; > > Hmm, you just started in Perl 5 mode. > > : $*VERSION = 1.3.2; > > Perl 5 would get confused here, so I'm presuming Perl

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-27 Thread Larry Wall
On Thu, Oct 27, 2005 at 05:37:13AM -0400, Rob Kinyon wrote: : Will I be able to do something like: : : package Foo; Hmm, you just started in Perl 5 mode. : $*VERSION = 1.3.2; Perl 5 would get confused here, so I'm presuming Perl 6. But Perl 6 isn't likely to let you override the global run-tim

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-27 Thread Rob Kinyon
On 10/26/05, Larry Wall <[EMAIL PROTECTED]> wrote: > On Wed, Oct 26, 2005 at 07:35:05PM -0700, chromatic wrote: > : On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote: > : > : > Plus, the argument is a straw man. Instead of: > : > > : > class Some::Class is also { > : > } > : > > : > you w

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread Luke Palmer
On 10/26/05, Rob Kinyon <[EMAIL PROTECTED]> wrote: > What about: > > class Foo is also { > method foo() { ... } > } > > Where the second foo() is no longer what the first foo() did. Just overwrite the vtable. > Furthermore, let's say you have: > > class Bar isa Foo { >

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread Larry Wall
On Wed, Oct 26, 2005 at 07:35:05PM -0700, chromatic wrote: : On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote: : : > Plus, the argument is a straw man. Instead of: : > : > class Some::Class is also { : > } : > : > you would do: : > : > class My::Version { : > does Some::C

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread chromatic
On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote: > Plus, the argument is a straw man. Instead of: > > class Some::Class is also { > } > > you would do: > > class My::Version { > does Some::Class; > } > > Problem solved. Don't forget the fun of modifying all existin

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread Rob Kinyon
On 10/26/05, Luke Palmer <[EMAIL PROTECTED]> wrote: [snip] > Okay, an open class means you can add methods to it, right? So, let's > say you have this class: > > class Foo { > method foo() {...} > method bar() {...} > } > > And this code: > > my Foo $x = Foo.new; >

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread chromatic
On Wed, 2005-10-26 at 19:22 -0600, Luke Palmer wrote: > But we find that many programmers make decisions that trade > readability and extensibility for an extra 1% of speed, even when they > are writing a command-line frontend to MPlayer[1]. If those people > are module writers, then we have a bu

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread Larry Wall
On Wed, Oct 26, 2005 at 08:48:12PM -0400, Rob Kinyon wrote: : If a role is an immutable class, that means that its internals cannot : be changed. Hence, the compiler can trust that it will be the same at : the end as at the beginning. Which means it's optimized. Which means : my objects run faster

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread Luke Palmer
On 10/26/05, Rob Kinyon <[EMAIL PROTECTED]> wrote: > On 10/26/05, chromatic <[EMAIL PROTECTED]> wrote: > > On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote: > > > > > I would prefer to use roles as they're closed by default, leaving > > > "class" to be my powertool, if I need the power. > > > >

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread Rob Kinyon
On 10/26/05, chromatic <[EMAIL PROTECTED]> wrote: > On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote: > > > I would prefer to use roles as they're closed by default, leaving > > "class" to be my powertool, if I need the power. > > I don't understand this desire; can you explain your reasoning?

Re: Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread chromatic
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote: > I would prefer to use roles as they're closed by default, leaving > "class" to be my powertool, if I need the power. I don't understand this desire; can you explain your reasoning? (NB: "closed" here, as I use it, still *does not* correspond

Roles vs. Classes (was Re: Ways to add behavior)

2005-10-26 Thread Rob Kinyon
> : 3) Aren't classes mutable and roles immutable by default only? Or has > : this changed? > > Of course. To change the default for a role, call it a class, and > to change the default for a class, call it a role. :-) Does this mean that roles are the recommended way to create immutable classes