Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This needs some docs, but I figured I'd throw out the short
> description to the list since they've come up, and we ought to finish
> them.
$ cat does.pasm
new P0, .Array
does I0, P0, "array"
print I0
does I0, P0, "scalar"
print I0
At 10:55 AM -0400 8/17/04, Gay, Jerry wrote:
> since presumably interfaces are a bit more uniquely named than
methods, and an object may be able to do something some class does
while not actually being in that class.
should interface names be registered somewhere?
Nope.
how are collisions handle
> since presumably interfaces are a bit more uniquely named than
> methods, and an object may be able to do something some class does
> while not actually being in that class.
>
should interface names be registered somewhere?
how are collisions handled?
i can imagine a scenario where multiple
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 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 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 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
42 matches
Mail list logo
