On Fri, 11 Oct 2002, Larry Wall wrote:
: You can certainly drop it within the methods,
: since there's also the accessor methods.
But I should point out that there's a semantic difference between
$.foo and .foo, in that $.foo is guaranteed to get my copy of the
attribute, while .foo might just go
On Thu, 10 Oct 2002, Larry Wall wrote:
: Anyway, I don't see offhand why composition can't simply be done with
: attributes as it is in C++, especially since attributes manifest as
: methods outside the class. I don't think $car.cd.eject() is all that
: horrible to contemplate.
By the way, ever
On Fri, Oct 11, 2002 at 05:02:02PM -0700, Larry Wall wrote:
> On Fri, 11 Oct 2002, Michael Lazzaro wrote:
> : On Friday, October 11, 2002, at 04:11 PM, Larry Wall wrote:
> : > has Nose $.snout;
> : > has Ear @.ears is cut("long");
> : > has Leg @.legs;
> : > has Tail $.tail is cut("shor
On Friday, October 11, 2002, at 04:11 PM, Larry Wall wrote:
> has Nose $.snout;
> has Ear @.ears is cut("long");
> has Leg @.legs;
> has Tail $.tail is cut("short");
>
> method Wag () {...}
> }
What's the rationale again for the dot in $.snout? Does it imply
On Tue, Oct 08, 2002 at 05:00:20PM -0400, Michael G Schwern wrote:
> Unfortunately, Java doesn't ship with JUnit nor do Java libraries usually
> ship with tests nor does a simple convention to run them nor an expectation
> that the user will run the tests before installing. Score one for Perl. :)
On Fri, 11 Oct 2002, Michael Lazzaro wrote:
: On Friday, October 11, 2002, at 04:11 PM, Larry Wall wrote:
: > has Nose $.snout;
: > has Ear @.ears is cut("long");
: > has Leg @.legs;
: > has Tail $.tail is cut("short");
: >
: > method Wag () {...}
: > }
:
: What's the r
On Mon, 7 Oct 2002, Andy Wardley wrote:
: Nicholas Clark wrote:
: > I think that the first syntax
: >
: > class Car::Q is Car renames(eject => ejector_seat)
: > is CD_Player renames(drive => cd_drive);
: >
: > makes it more clear that I'd like to pick and choose which methods
: > th
On Mon, 7 Oct 2002, chromatic wrote:
: On Wed, 02 Oct 2002 04:12:44 -0700, Michael G Schwern wrote:
:
: > I like the "class Vehicle is interface" as a shorthand for declaring every
: > method of a class to be an interface.
:
: Perhaps associating a property with a class can be shorthand for asso
On Mon, 30 Sep 2002, Michael G Schwern wrote:
: On Tue, Oct 01, 2002 at 01:36:19AM +0100, Simon Cozens wrote:
: > [EMAIL PROTECTED] (Michael G Schwern) writes:
: > > method _do_internal_init ($num) is private {
: >
: > Just thinking aloud, would
: > sub foo is method is private is inte
Take a look at:
http://java.sun.com/products/jdk/1.2/docs/guide/collections/designfaq.html
Either you agree with the answer to "Core Interfaces" questions 1 and 2 or
you don't. There are tradeoffs to be made, and I think they made some
reasonable choices, though others are free to think otherwis
On Tue, Oct 08, 2002 at 05:03:26PM -0400, Trey Harris wrote:
> > It really ought to be one of those "sure you can do this, but please don't"
> > things.
>
> It's a RuntimeException. You can't require that all RuntimeExceptions be
> declared if thrown;
> You can subclass RuntimeException. So if
In a message dated Tue, 8 Oct 2002, Michael G Schwern writes:
> On Sun, Oct 06, 2002 at 06:17:37PM -0400, Daniel B. Boorstein wrote:
> > I think there may be some confusion here. In java, there's no special syntax
> > to declare a method an optional part of the interface. All concrete classes
> >
On Sun, Oct 06, 2002 at 11:57:51PM -0400, Noah White wrote:
> I wouldn't call it a dirty little secret as Michael put it :-).
> This is the right thing to do within the context of a contract. The
> contract does not guarantee that method functionality implemented by a
> concrete cl
On Sun, Oct 06, 2002 at 06:17:37PM -0400, Daniel B. Boorstein wrote:
> I think there may be some confusion here. In java, there's no special syntax
> to declare a method an optional part of the interface. All concrete classes
> that implement the Collection interface still must define full-bodie
On Wed, 02 Oct 2002 04:12:44 -0700, Michael G Schwern wrote:
> I like the "class Vehicle is interface" as a shorthand for declaring every
> method of a class to be an interface.
Perhaps associating a property with a class can be shorthand for associating
that property with every method of the cl
On Sunday 06 October 2002 09:57 pm, Michael G Schwern wrote:
> On Sun, Oct 06, 2002 at 01:49:26AM -0400, Noah White wrote:
> > >OTOH, Java interfaces have a loophole which is considered a design
> > >mistake.
> > >An interface can declare some parts of the interface optional and then
> > >implemen
Nicholas Clark wrote:
> I think that the first syntax
>
> class Car::Q is Car renames(eject => ejector_seat)
> is CD_Player renames(drive => cd_drive);
>
> makes it more clear that I'd like to pick and choose which methods
> the composite object gets from which parent.
But now you'
On Sunday, October 6, 2002, at 06:17 PM, Daniel B. Boorstein wrote:
[SNIP]
> I think there may be some confusion here. In java, there's no special
> syntax
> to declare a method an optional part of the interface. All concrete
> classes
> that implement the Collection interface still must defi
On Sun, Oct 06, 2002 at 01:49:26AM -0400, Noah White wrote:
> >OTOH, Java interfaces have a loophole which is considered a design
> >mistake.
> >An interface can declare some parts of the interface optional and then
> >implementors can decide if they want to implement it or not. The
> >upshot
>
On Tue, Oct 01, 2002 at 04:01:26PM -0700, Michael Lazzaro wrote:
>
> >On Tue, Oct 01, 2002 at 03:43:22PM -0400, Trey Harris wrote:
> >>You want something like
> >>
> >> class Car is Vehicle renames(drive => accel)
> >>is MP3_Player renames(drive => mp3_drive);
>
> I *really* like th
On Monday, September 30, 2002, at 08:23 PM, Michael G Schwern wrote:
> OTOH, Java interfaces have a loophole which is considered a design
> mistake.
> An interface can declare some parts of the interface optional and then
> implementors can decide if they want to implement it or not. The
> u
On Tue, Oct 01, 2002 at 02:49:49PM -0700, Michael Lazzaro wrote:
> >>My musing is that the behavior of a class in different contexts is
> >>itself an interface, in the sense of being a contract between a
> >>class/subclass and it's users
> >
> >Ah HA! Contract! Return values can be enforce via a
On Tue, Oct 01, 2002 at 04:01:26PM -0700, Michael Lazzaro wrote:
> >On Tue, Oct 01, 2002 at 03:43:22PM -0400, Trey Harris wrote:
> >>You want something like
> >>
> >> class Car is Vehicle renames(drive => accel)
> >>is MP3_Player renames(drive => mp3_drive);
>
> I *really* like this,
On Tue, Oct 01, 2002 at 05:04:29PM -0700, Michael Lazzaro wrote:
> On Tuesday, October 1, 2002, at 02:49 PM, Michael Lazzaro wrote:
> >Which implies, I assume, that "interface" is not the default state of
> >a class method, e.g. we do need something like "method foo() is
> >interface { ... }" t
On Tuesday, October 1, 2002, at 02:49 PM, Michael Lazzaro wrote:
> Which implies, I assume, that "interface" is not the default state of
> a class method, e.g. we do need something like "method foo() is
> interface { ... }" to declare any given method
Flippin' hell, never mind. You're almost
On Monday, September 30, 2002, at 11:19 PM, Michael G Schwern wrote:
> On Mon, Sep 30, 2002 at 06:04:28PM -0700, David Whipp wrote:
>> On a slightly different note, if we have interfaces then I'd really
>> like to follow the Eiffel model: features such as renaming methods
>> in the derived class
> On Tue, Oct 01, 2002 at 03:43:22PM -0400, Trey Harris wrote:
>> You want something like
>>
>> class Car is Vehicle renames(drive => accel)
>> is MP3_Player renames(drive => mp3_drive);
I *really* like this, but would the above be better coded as:
class Car is Vehicle ren
On Tuesday, October 1, 2002, at 12:33 PM, Michael G Schwern wrote:
> Perhaps a way to sharpen the focus on this is to expand the discusson
> of
> strictness to include not just method prototypes but Design-By-Contract
> features as well (pre and post conditions and invariants). Should DBC
> co
On Tue, Oct 01, 2002 at 03:43:22PM -0400, Trey Harris wrote:
> You want something like
>
> class Car is Vehicle renames(drive => accel)
> is MP3_Player renames(drive => mp3_drive);
>
> Either of those renamings is, of course, optional, in which case drive()
> refers to the non-rena
In a message dated Mon, 30 Sep 2002, Michael G Schwern writes:
> On Mon, Sep 30, 2002 at 06:04:28PM -0700, David Whipp wrote:
> > On a slightly different note, if we have interfaces then I'd really
> > like to follow the Eiffel model: features such as renaming methods
> > in the derived class may
On Tue, Oct 01, 2002 at 11:51:02AM -0700, Michael Lazzaro wrote:
> >This comes down to an OO philosophy issue. If Perl 6 wants a strict OO
> >style, don't put in a loophole. If they want to leave some room to
> >play,
> >put in the ability to turn some of the strictness off.
>
> I guess what b
On Monday, September 30, 2002, at 05:23 PM, Michael G Schwern wrote:
> OTOH, Java interfaces have a loophole which is considered a design
> mistake.
> An interface can declare some parts of the interface optional and then
> implementors can decide if they want to implement it or not. The
> u
On Mon, Sep 30, 2002 at 11:16:20PM -0400, Michael G Schwern wrote:
> How about seperated by commas, like any other list?
>
> method foo is fungible, private, integer {
Well, if we're going to use a /list/, how about
method foo ($param) ^is (fungible, private, integer) {
?
:)
On Mon, Sep 30, 2002 at 06:04:28PM -0700, David Whipp wrote:
> On a slightly different note, if we have interfaces then I'd really
> like to follow the Eiffel model: features such as renaming methods
> in the derived class may seem a bit strange; but they can be useful
> if you have have name-conf
On Tue, Oct 01, 2002 at 01:36:19AM +0100, Simon Cozens wrote:
> [EMAIL PROTECTED] (Michael G Schwern) writes:
> > method _do_internal_init ($num) is private {
>
> Just thinking aloud, would
> sub foo is method is private is integer is fungible {
>
> be better written as
> su
Michael Lazzaro wrote:
> > What if a subclass adds extra, optional arguments to a
> > method, is that ok?
>
> This is the scariest question, I think... In theory, yes, there are
> lots of potential interfaces that would benefit from optional
> extensions, & I've made a few. In strict terms,
[EMAIL PROTECTED] (Michael G Schwern) writes:
> method _do_internal_init ($num) is private {
Just thinking aloud, would
sub foo is method is private is integer is fungible {
be better written as
sub foo is fungible private integer method {
or not?
--
Those who do not un
On Mon, Sep 30, 2002 at 10:12:48AM -0700, Michael Lazzaro wrote:
> Heck, I'll jump into this one, since I've been working in _way_ too
> many OO variations lately, some of them inflicted upon myself. While I
> hope perl6 will allow extendable OO methodologies, the out-of-box one
> needs to be
On Sunday, September 29, 2002, at 05:11 PM, Michael G Schwern wrote:
> Here's some open problems:
>
> Would this be the default behavior for overridden methods, or will the
> parent class/methods have to be declared "is interface" for the
> signatures
> to be enforced on subclasses?
Heck, I'll
39 matches
Mail list logo
