On Fri, May 07, 2004 at 01:39:43PM -0400, Austin Hastings wrote:
: I agree: classes have a chance to pre-specify the class
: signatures, and objects get a chance to dynamically agree to
: undertake method calls.
:
: The timeframe I was thinking of was object construction time.
I don't see the val
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Friday, 07 May, 2004 12:40 PM
> To: Perl6 Language
> Subject: Re: Specifying class interfaces with AUTOMETH
>
> : This seems an awkward way to implement dispatch, since the
> : price of usin
On Wed, May 05, 2004 at 08:12:24PM -0400, Austin Hastings wrote:
: Apparently the AUTOMETH code will be invoked to determine what code matches
: a request. AUTOMETH will "return a reference to" a matching method. This
: implies that AUTOMETH is expected to resolve dispatch within the class --
: "He
I was looking at *Unit the other day, and at the very satisfying "Mock
Objects" systems that have grown up around them for automated testing.
In a Decorator/delegation context, it seems like yet another case where
there's two ways to do things:
1- In(tro)spect the classes you want to replicate/ex
On Thu, Mar 06, 2003 at 10:16:40AM +, Simon Cozens wrote:
: > Like mixins? Perhaps something like this:
: >
: > class My::Class;
: > mixin My::Random::Number::Generator qw( rand );
: > mixin My::Serialisation::Marshall qw( freeze thaw );
:
: Yey! With this, the Perl6-o-meter now stands
[EMAIL PROTECTED] (Andy Wardley) writes:
> Like mixins? Perhaps something like this:
>
> class My::Class;
> mixin My::Random::Number::Generator qw( rand );
> mixin My::Serialisation::Marshall qw( freeze thaw );
Yey! With this, the Perl6-o-meter now stands at:
PERL 5
Sam Vilain wrote:
> No. All I'm saying is that this sort of construct:
>
>*{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
Like mixins? Perhaps something like this:
class My::Class;
mixin My::Random::Number::Generator qw( rand );
mixin My::Serialisation::Marshall qw( fre
On Thu, 06 Mar 2003 16:22, Brent Dax wrote:
> Who said it would be silent? I mentioned emitting a warning below. The
> module writer will fix the warning, and module users can disable the
> warning easily until the new version is out.
> # It sounds like you already have a plan - I didn't realise
Sam Vilain:
# > Alternatively, the approach taken with MI namespace clashes
# in Perl 5
# > is to let the programmer arrange the inheritance tree as he
# sees fit,
#
# You are right - but this is a different condition. There is
# no error in
# this case because there is no ambiguity as to w
On Thu, 06 Mar 2003 15:31, Brent Dax wrote:
> Sam Vilain:
> # > We musn't dictate style.
> #
> # No, but we should emanate good style. And I consider opening
> # two class'
> # namespaces into the same stash to be very bad style.
>
> We *must* support MI
Sam Vilain:
# > We musn't dictate style.
#
# No, but we should emanate good style. And I consider opening
# two class'
# namespaces into the same stash to be very bad style.
We *must* support MI, delegation and interfaces in Parrot. Interfaces
can probably be implemented in te
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:02 AM +1300 3/6/03, Sam Vilain wrote:
> > *{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
> > Gives you everything that inheriting a class does, apart from the
> > ->isa() relationship. And potential unwanted namespace pollution.
>
At 5:02 AM +1300 3/6/03, Sam Vilain wrote:
No. All I'm saying is that this sort of construct:
*{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
Gives you everything that inheriting a class does, apart from the ->isa()
relationship. And potential unwanted namespace pollution.
It's
> > And I'm coming in late on this. Are you saying you want
> > Exporter/%EXPORT_TAGS functionality built into the language and
> > into all objects? Wouldn't that jack up the overhead?
>
> No. All I'm saying is that this sort of construct:
>
>*{$_} = \&{"Class::$_"} foreach (qw(method metho
On Thu, 06 Mar 2003 04:19, Paul wrote:
> Are you speaking in terms of limitation, or requirement?
> It would be nice to have a syntax solution. I've seen p5 interfaces
> with stubs that die so that you have to override them in a subclass. It
> works, but seems a little kludgy.
&g
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
need a more flexible syntax for specifying how interfaces
: should be constructed in the case of composed objects, rather than
: turning composition into inheritance to avoid the problem.
Yes, that's important. If you've got a CD_Player *object*, it doesn't
do anyone any good to pre
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 ar
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 t
gets from which parent.
But now you've turned composition back into inheritance, and I think it's
important to be able to distinguish between the two.
The car is definately not a CD player, it just has one.
I think we need a more flexible syntax for specifying how interfaces
should be c
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
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
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,
}
Definately not that.
> - or -
> class Vehicle is interface {
> ...
> }
>
> class Vehicle {
> method foo () is interface { ... }
> method bar () is interface { ... }
> method zap ()
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 metho
> 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
Should DBC
> conditions be overridable? Since it's not terribly useful to override
> a
> signature only to be stopped by a pre-condition.
>
> Taken as a whole, I'm leaning towards no. Interfaces and conditions
> should
> be strict. They can be gotten around using de
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
>
ecause it's being
used in an unforseen manner. But they have to explicitly say they're
violating it.
I can't see any good reason why an interface author would want to make their
interface optional.
If we do it strictly, interfaces are not optional.
Perhaps a way to sharpen the focu
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
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 y
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
[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
make the case that yes, you should have to say "is
> interface", if that's what you mean.
>
> The reason being "private" methods; while the interfaces to an object
> must remain consistent, I don't think we should enforce the same rigor
> on internal
#x27;s what you mean.
The reason being "private" methods; while the interfaces to an object
must remain consistent, I don't think we should enforce the same rigor
on internal methods of a class. There are cases where you want
something like:
method do_internal_initialization
erl 6 support interfaces?" meaning Java style interfaces.
Figuring that we now have proper subroutine prototypes and assuming forward
declarations stayed in the language, sure we'd effectively have interfaces.
Thinking on it afterwards, there's a bit more to it that that.
If I was to decla
Melvin Smith wrote:
> I see the potential for another Perl 'non-warning' bug, where
> someone typed:
>
> class Appliance {
> ...mucho lines of code...
> }
>
> class Toaster is appliance {
> ...
> }
That's probably an "Undefined property 'appliance' ascribed to class Toaster" error.
> It sca
Melvin Smith writes:
: At 07:12 AM 4/5/2002 +1000, Damian Conway wrote:
: >Melvin Smith wrote:
: >More generally, it also depends whether you think of out-of-band properties as
: >nouns or adjectives. For example:
: >
: > class Toaster is silver is shiny is hot is little {...}
: >
: >vs:
:
At 07:12 AM 4/5/2002 +1000, Damian Conway wrote:
>Melvin Smith wrote:
>More generally, it also depends whether you think of out-of-band properties as
>nouns or adjectives. For example:
>
> class Toaster is silver is shiny is hot is little {...}
>
>vs:
After rereading the example, this one
At 07:12 AM 4/5/2002 +1000, Damian Conway wrote:
>Melvin Smith wrote:
>
> > 1) In Perl6 we can tag metadata properties to an object using the 'is'
> keyword.
>
>Err, no. We can add properties to a *class* using C.
>To tag objects (which are run-time phenomena) we'd use C.
Oops, ok this was my mi
Melvin Smith wrote:
> 1) In Perl6 we can tag metadata properties to an object using the 'is' keyword.
Err, no. We can add properties to a *class* using C.
To tag objects (which are run-time phenomena) we'd use C.
> 2) Also, in Perl6 we can derive a new class from an ancestor using 'is'.
Corre
Reading Apoc and Exeg 4 I liked most everything. It has already
been said many times how Perl6 is finally getting features
the OO guys have been wanting forever, so I won't state the
obvious again, but I would like to propose an alternate keyword...
1) In Perl6 we can tag metadata properties to a
61 matches
Mail list logo
