Sam,
Just wondering what the status is on python/parrot/pirate/pyrate.
These both look outdated.
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip
http://pirate.versionhost.com/viewcvs.cgi/pirate/
Is there a up to date cvs repo?
Can we get this code checked into the parrot svn repo?
Kevin
Sam Ruby [EMAIL PROTECTED] wrote:
As long as find_method itself can be overridden, this above is merely a
description of the default behavior, not a hard requirement.
Yes, of course. Cfind_method *is* overridable and, as all method lookup
is calling Cfind_method, the code can do whatever is
There was already some discussion about splitting the VTABLE structure
into distinct pieces. I'd like to start that task after 0.1.2 is out.
Here are some thoughts:
1) Vtable and interfaces
The VTABLE structure provides common slots that every PMC must provide
and optional parts that roughly
Leopold Toetsch wrote:
2) Vtable entries should be real methods
All non-defaulted, non-inherited entries of a vtable interface should be
available as methods, like now with the METHOD keyword. This allows
eventually code like this:
Px = Py.__pop_pmc()
or
Px = Py.__string()# $x =
At 8:54 PM -0700 8/16/04, chromatic wrote:
On Mon, 2004-08-16 at 11:30, Michel Pelletier wrote:
I've noticed there are ops for interfaces, but no implementation or ppd
yet.
Perl 6 has roles which are much more useful than interfaces -- in fact,
interfaces are degenerate roles. See Apocalypse 12
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.
For parrot, interfaces are *very* simple things. An interface is a
string tag which can be attached to a class. Each class can have
multiple interface tags
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
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
end
$ parrot does.pasm
10
TODO is AFAIK walk the parent chain and define some standard names for
known interfaces we provide. And the dynamic variants of interface
changes.
The class compiler understands:
pmclass Class ... does foo does bar
leo
On Mon, 16 Aug 2004 20:54:34 -0700
chromatic [EMAIL PROTECTED] wrote:
On Mon, 2004-08-16 at 11:30, Michel Pelletier wrote:
I've noticed there are ops for interfaces, but no implementation or
ppd yet.
Perl 6 has roles which are much more useful than interfaces -- in
fact, interfaces
I've noticed there are ops for interfaces, but no implementation or ppd
yet.
Is it too premature to start thinking about this? Interfaces happen to
be something I take a lot of interest in, I was one of Zope developers
who first worked on Jim Fulton's scarecrow Python interface
implementation
On Mon, 2004-08-16 at 11:30, Michel Pelletier wrote:
I've noticed there are ops for interfaces, but no implementation or ppd
yet.
Perl 6 has roles which are much more useful than interfaces -- in fact,
interfaces are degenerate roles. See Apocalypse 12 for more.
http://www.perl.com
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 --
: Here
-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 using AUTOMETH is being able to write
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
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
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( freeze
[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
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 at:
--- 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.
It's
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.
And I'm coming in late
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 method2
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
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 terms of MI
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, delegation and interfaces in Parrot. Interfaces
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
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
#
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(short);
:
:
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 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 that
it
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
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 rationale
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 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 integer
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
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 pretend it's a car *object*. We too often
lose sight of the fact
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-bodied
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 class
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
that
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;
snip
You can subclass RuntimeException. So if Sun
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 otherwise
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
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 constructed in the case of composed objects, rather
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, but would the
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 define
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
{
...
}
snip
class Vehicle {
method foo () is interface { ... }
method bar () is interface { ... }
method zap () is private { ... }
}
Perhaps both of the above, but only if methods-as-interfaces have to be
explicitly declared. I like
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, but would the
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 simple DBC
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 may
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 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
. 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 focus on this is to expand the discusson of
strictness to include
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 seem
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-renamed one
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 delegation, which should be
built into Perl 6 anyway
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 renames(drive
thought I was going to argue that it should be the default
behavior (to avoid yet more cruft in the method prototype) but thinking
about it more, I'll 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
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 methods of a class.
Internal methods would simply be declared private and not be inherited, so
its
[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
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, though
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
sub foo is
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
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) {
?
:)
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 declare an abstract class
On Sun, 2002-08-18 at 18:53, Brent Dax wrote:
# And do we need a RFC like definition of should/may/must/mustn't?
If so, I'd suggest the definition be patched into PDD0, so it's shared
by all PDDs instead of repeating the definitions everywhere.
Noted.
--
Bryan C. Warnock
Brent Dax [EMAIL PROTECTED] writes:
Some comments on this
=item CParrot_String Parrot_string_new(Parrot_Interp, char* bytes,
Parrot_Int len, Parrot_String enc)
Allocates a Parrot_String and sets it to the first Clen bytes of
Cbytes. Cenc is the name of the encoding to use (e.g. ASCII,
On Sat, Aug 17, 2002 at 03:58:32PM -0700, Brent Dax wrote:
=head2 Strings
Parrot-level CStrings are to be represented by the type
CParrot_String. This type is defined to be a pointer to a Cstruct
parrot_string_t.
The functions for creating and manipulating CParrot_Strings are listed
Nicholas Clark:
# The functions for creating and manipulating CParrot_Strings are
# listed below.
#
# Is it worth arranging a reminder in here that as parrot is
# garbage collected there is no confusion about who owns
# pointers to blah?
Probably. (Actually, I'd probably put it in a
The POD below my sig is a proposed PDD on external data interfaces, that
is, the way embedders and extenders will access Parrot's data types. It
covers Strings, Buffers, and PMCs, as well as a few related functions.
Let me know what you think.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot
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 scares me to be
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 bugs
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:
:
:
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
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 Cis.
To tag objects (which are run-time phenomena) we'd use Cbut.
2) Also, in Perl6 we can derive a new class from an ancestor using 'is'.
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 Cis.
To tag objects (which are run-time phenomena) we'd use Cbut.
Oops, ok this was my
The attached PDDs cover embedding and interfaces shared between
embedding and extending (external interfaces). The embedding PDD
mostly covers stuff already in the core; the external interface PDD is
my proposed solution.
Read and review, please.
--Brent Dax [EMAIL PROTECTED]
@roles=map
Dan Sugalski [EMAIL PROTECTED] wrote:
[vtable stuff snipped]
I don't think it's too early to be dealing with the way variables are
implemented, at least at some level.
I agree; I didn't mean for it to sound like I was saying otherwise.
Also, just because we do vtables under the hood
78 matches
Mail list logo
