Re: Loop controls
On Tuesday, April 30, 2002, at 01:22 PM, Dan Sugalski wrote:
> At 1:07 PM -0400 4/30/02, Miko O'Sullivan wrote:
>> > Damian, now having terrible visions of someone suggesting
>> C ;-)
>>
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep,
>> elstry ...
>
> Has anyone brought up elselse or unlessunless yet?
All of this is a bit silly, but if loops in Perl6 had some sort of
boolean value of their own, then it seems the language already has a way
to approach this. Scoping might be a problem, but...
for @foo -> $bar {
...
} // print "The loop didn't... uh... loop.\n";
Just a thought.
Re: Accessor methods ?
On Thursday, May 9, 2002, at 03:16 PM, Aaron Sherman wrote:
> Then you can declare them as such:
>
> sub get_bar() { .bar }
> sub get_baz() { .baz }
> sub set_baz($newbaz) { .baz = $newbaz }
Seeing this, an idea mildly Eiffel-ish comes to mind. Could we get away
with something like the following?
method set_baz(type($.baz) $newbaz) { $.baz = $newbaz }
Which would force the new value to be of the same type as the current
value, without having to strongly declare the type of the variable
elsewhere. Sort of like, in Perl5...
sub set_baz {
my $self = shift;
if (@_) {
my $new_baz = shift;
$new_baz_type = ref($new_baz) || "SCALAR";
$current_baz_type = ref($self->{baz}) || "SCALAR";
$self->{baz} = new_baz if $new_baz_type eq $current_baz_type;
}
return $self->{baz};
}
or in Eiffel...
set_baz(new_baz: like baz) is
do
baz := new_baz
end
Re: Accessor methods ?
On Friday, May 10, 2002, at 09:54 PM, Damian Conway wrote:
> That's getting a little ugly, so maybe we'd "lift" the syntax from
> Eiffel instead:
>
> method set_baz($newbaz is like($.baz)) { $.baz = $newbaz }
This is exactly what went through my mind about a half second after I
posted the message.
$newbaz is like($.baz), I would think, would have to raise a run-time
exception if $newbaz isn't "like" $.baz. Where would the exception be
handled, though? Inside the method/subroutine, or outside of its scope?
Selective exporting of properties/methods
While thinking Eiffel-ish thoughts the other day, I began to wonder if
Perl6's classes could go beyond the simple private/public/protected
scheme by optionally allowing for a property or method to only be
accessed by a certain set of classes. For instance(as I understand
Perl6 syntax):
class Foo {
method hello is public {
return "hello";
}
method world is public_to(Bar) {
# is only public to objects of class Bar
return "world";
}
}
class Bar {
method say_hello {
# this works fine
print Foo.new.hello, "\n";
}
method say_world {
# as does this
print Foo.new.world, "\n";
}
}
class Baz {
method say_world {
# generates a run-time exception for trying to call a private method.
print Foo.new.world, "\n";
}
}
Re: Selective exporting of properties/methods
On Sunday, May 12, 2002, at 02:18 PM, Miko O'Sullivan wrote:
>> While thinking Eiffel-ish thoughts the other day, I began to wonder if
>> Perl6's classes could go beyond the simple private/public/protected
>> scheme by optionally allowing for a property or method to only be
>> accessed by a certain set of classes.
>
> Many times when I've used OO languages I've wished for something like
> this.
> What I've often wanted would be standard method that is called before
> every
> subroutine call. If that method returns false then the method that was
> called is not called.
I think maybe what you're looking for is another Eiffel/Sather-ism. I
know Eiffel at least has both pre and post-conditions that look
something like this(it's been a while, so if this isn't quite right):
class
ACCOUNT
creation
make_with_balance
feature { BANK }
balance: INTEGER
make_with_balance(initial_balance: INTEGER) is
require
initial_balance >= 0
do
balance := initial_balance
ensure
balance >= 0
end
end
I too have thought this might be useful in Perl6. Perhaps...
class Account {
my INT $balance;
method new(INT $initial_balance //= 0) {
REQUIRE { $initial_balance >= 0; }
$.balance = $initial_balance;
ENSURE { $.balance >= 0; }
}
}
Re: Selective exporting of properties/methods
On Wednesday, May 15, 2002, at 10:17 AM, Aaron Sherman wrote:
> On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
>
>> method world is public_to(Bar) {
>
> Might as well make that:
>
> method world is private(Bar)
>
> I tend to take any opportunity to recycle syntax, plus keywords with
> underscores give me gas. ;)
I had considered "is public(Bar)", but this works too.
A Perl 6 class question
Since Adam Lopesto asked a non-regex question, I don't feel quite as out
of place for doing the same.
This one actually came to me just the other night. Would it be possible
in Perl 6 to create "anonymous classes"? Something like:
my $foo_class = class {
method new {
# yada yada yada
}
}
my $foo_obj = $foo_class.new;
Re: A Perl 6 class question
On Saturday, August 10, 2002, at 06:25 PM, Piers Cawley wrote:
> Chris Dutton <[EMAIL PROTECTED]> writes:
>
>> Since Adam Lopesto asked a non-regex question, I don't feel quite as
>> out of place for doing the same.
>>
>> This one actually came to me just the other night. Would it be
>> possible in Perl 6 to create "anonymous classes"? Something like:
>>
>> my $foo_class = class {
>> method new {
>> # yada yada yada
>> }
>> }
>>
>> my $foo_obj = $foo_class.new;
>
> I hope so.
The only problem I could see, and I wanted to wait for at least one
other opinion before mentioning this, is rewriting the above as:
my $foo_class $foo_obj = $foo_class.new;
Still I can see this as occasionally being useful for having instance
variables which can effectively be initialized, but afterwards are
constant. Then again, there's probably another, more graceful way to do
this using the new method and properties.
sub foo(int $bar //= 0) {
return class {
int $.baz is constant = $bar;
method out(int $multiply_by //= 1) {
print $.baz * $multiply_by, "\n";
}
}
}
foo(5).new.out(2); # 10
foo(6).new.out(3); # 18
Re: A Perl 6 class question
On Monday, August 12, 2002, at 01:27 PM, Allison Randal wrote:
> On Sat, Aug 10, 2002 at 07:30:19PM -0400, Chris Dutton wrote:
>>
>> The only problem I could see, and I wanted to wait for at least one
>> other opinion before mentioning this, is rewriting the above as:
>>
>> my $foo_class $foo_obj = $foo_class.new;
>
> I'm not exactly sure what you're trying to do with this.
Sort of like:
class A { ... }
my A $a = A.new;
Where A is $foo_class. Probably not terribly useful, but I just
wondered if it'd work anyway.
> You can create
> an object within the same statement as you define the class:
>
> my $foo_obj = class {
> method new {
> # yada yada yada
> }
> }.new;
I figured that would work, but wasn't entirely sure. Thanks.
>> sub foo(int $bar //= 0) {
>> return class {
>> int $.baz is constant = $bar;
>> method out(int $multiply_by //= 1) {
>> print $.baz * $multiply_by, "\n";
>> }
>> }
>> }
>>
>> foo(5).new.out(2); # 10
>> foo(6).new.out(3); # 18
>
> As it stands, you're not gaining anything over:
>
> sub foo(int $bar //= 0, int $multiply_by //= 1) {
> print $bar * $multiply_by, "\n";
> }
>
> foo(5,2);
Granted, it was a trivial example. :-)
> attr int $.baz is constant = $bar;
I like it.
>> foo(5).new.out(2); # 10
>
> I suspect this will be allowable syntax. But if you find yourself using
> it you might want to re-think the code. Creating a class and an object
> for single use isn't tremendously efficient. Then again, you may be
> golfing. :)
Hmmm could I have instead written the following and ended up with
both a lexically scoped anonymous class($fc), and an instance($fo)?
( my $fo = ( my $fc = foo(5) ).new ).out;
One thing is obvious... it's been way too long since I read the various
Exegesis documents.
Just reading up on Pike...
and this just jumped out at me:
class Foo {
private string|int bar;
static create(string|int newBar) {
bar = newBar;
}
}
In other words, as I understand it, you can type the variable bar as
either an int or a string.
Aside from simply, "my $bar;", will we be able to repeat this behavior
in Perl6 programs?
Let me guess, though, this is one of those instances where I should have
read A1..5 and E1..4 more closely. :-)
Ok, Pike is... (was: Perl 6 Summary for week ending 2002-08-18)
Explained far more throughly at http://pike.ida.liu.se/ than I can in an e-mail. It really looks like an intriguing language, with a (supposedly) very fast runtime, (again, supposedly) beating Perl, Python, Tcl, and Java in execution times. Unfortunately I've been unable to get it to compile anything successfully after building the compiler, due to an error regarding a file (master.pike) that doesn't appear to even be in the source distribution.
A few thoughts on inheritance
We are supposedly going to be able to set a class to be "uninheritable". Will we be able to set a single method or attribute to be uniherited by any subclasses? Please forgive me if this is one of the seven deadly OO sins. I haven't yet had any formal education with regards to programming(aside from a short intro class using Fortran, but I've almost completely repressed those memories). Also, I think this might have been discussed and I just didn't catch the answer, but can a method be declared in such a way that no subclass may redefine it? In cases of multiple inheritance, will we be able to specifically say "don't inherit method 'z' from class C, where the inheritance looks like the following: A / \ / B - redefine method "z" / \ C D \ / \ / \ / E So instead, class E inherits method "z" from class D, which inherits it from class B, rather than getting the original from class A via class C. I'm a little bit afraid that trying to do inheritance as it at least *looks* right now will limit the flexibility of it. I'm not sure how this psuedo-code to accomplish the above would translate into Perl6. class E inherit C except z end # or... # inherit C #rename z as C_z # end inherit D end
Re: Interfaces
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 seem a bit strange; but they can be useful >> if you have have name-conflicts with multiple inheritance. > > I'm not familiar with the Eiffel beyond "it's the DBC language and it's > French", but wouldn't this simply be covered by aliasing? Eiffel can either rename a "feature"(method, attribute), which is pretty much the same as aliasing as you might see it in Ruby, or you can redefine the method entirely. Again, you also would see this in Ruby, which might be more approachable for those familiar with Perl. class BAR inherit FOO rename output as old_output end end or... class BAR inherit FOO redefine output end end
Re: Private contracts?
On Thursday, October 3, 2002, at 05:19 PM, Michael G Schwern wrote: > On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote: >> With pre/post conditions, a subclass is allowed to weaken the >> preconditions or strengthen the postconditions. > > How exactly does one "weaken" a precondition? At least in Eiffel, if you redefine a method, you may not give it stringer preconditions than the original method, but you may have stronger postconditions. In essence, you're not requiring any more of the client, but you can ensure more to them on completion, thus maintaining the parent's contract.
Re: Private contracts?
On Friday, October 4, 2002, at 06:23 PM, [EMAIL PROTECTED] wrote: > On Fri, Oct 04, 2002 at 09:13:45AM -0400, Chris Dutton wrote: >>> How exactly does one "weaken" a precondition? >> >> At least in Eiffel, if you redefine a method, you may not give it >> stringer preconditions than the original method, but you may have >> stronger postconditions. In essence, you're not requiring any more of >> the client, but you can ensure more to them on completion, thus >> maintaining the parent's contract. > > But what does it mean to be "stronger"? How does Eiffel figure out if > a given precondition is "stronger" or "weaker" than another? Perhaps an example is the best way to demonstrate this: class FOO creation make feature make(input: SOME_OTHER_CLASS) is require input /= Void do -- something here ensure input /= Void end end -- Good: class BAR inherit FOO redefine make end creation make feature make(input: SOME_OTHER_CLASS) is -- no requirements, weaker precondition do -- yada yada ensure input /= Void old input.some_attribute /= input.some_attribute -- stronger postcondition is ok. end end -- Bad: class BAR inherit FOO redefine make end creation make feature make(input: SOME_OTHER_CLASS) is require input /= Void input.some_attribute = 1 -- requiring more than the parent's make procedure is bad. do -- yada yada -- Not ensuring anything to the client is bad. -- The parent honored that in its contract, so -- the child must also. end end
Re: Draft Proposal: Attributes: "public" vs. "private"
On Sunday, October 6, 2002, at 12:57 AM, Noah White wrote:
>>
>>> Note that an alternate definition of "private" is often used, as
>>> follows:
>>>
>>> A "private" attribute is an attribute whose scope is restricted
>>> such that
>>> it may be accessed only within the class in which it has been
>>> declared,
>>> OR WITHIN ANY CLASS THAT INHERITS FROM THAT CLASS.
>>
>> I'll agree with that.
>>
>
> ACK! After re-reading this I about puked. No, that notion of private
> would not be something I'd agree with :-) That's more like protected.
As I think I've mentioned once before, and will again as Eiffel's been
mentioned recently...
Is there any chance Perl6 could simply avoid the can of worms that is
public/private/protected and have a single accessibility property? It
would seem to clean the debate up handily, and provides even greater
flexibility for programmers. Along the lines of:
class Foo {
attr $.bar is accessible(Bar, Baz);
# Makes $.bar attribute accessible only to the Bar and Baz classes.
attr $.baz is accessible(Foo);
# Protected
attr $.hello is accessible(None);
# explicitly Private
attr $.world is accessible(Any);
# Public
}
Of course, if Perl6 went down this road, Ruby-ish read, write, or
read/write attributes would also be nice. I might want to let another
class read an attribute, but not write to it, while I might for some
reason want another class to be able to write to an attribute, but not
read it. But maybe I'm just weird that way. :-)
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
One first thing I notice while I'm supposed to be doing homework. :-) Wasn't "class MyClass;" supposed to work along the line of Perl5's "package MyClass;" and make everything following that statement the definition of MyClass?
Re: Fw: perl6 operator precedence table
On Wednesday, October 9, 2002, at 05:03 PM, Trey Harris wrote: > In a message dated Wed, 9 Oct 2002, Michael Lazzaro writes: > >> >> Uh-oh: my life is gonna suck. I've spent days hunting obscure bugs >> that were caused by a single mistyped character. Now I'll be spending >> days hunting obscure bugs that were caused by a single *pixel*. >> > > I've already been there, my friend. :-) MacOS X's pretty anti-aliased > fonts make it impossible to tell the difference between colon and > semi-colon at small type sizes. It didn't used to matter, but now it > really does. I have a hot key to make my terminal's font bigger > whenever > I'm reading perl6 mail. :-) Andale Mono is all fun and games until someone loses half an hour of their life to: int x, y, z: char ch; :-)
Re: Private contracts?
On Saturday, October 12, 2002, at 01:10 PM, Luke Palmer wrote:
>> Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
>> From: Larry Wall <[EMAIL PROTECTED]>
>>
>> If we use | and & as sugar for any() and all(), then their precedence
>> should probably be the same as || and &&.
>
> Should they? I had in mind something just above comparisons. That
> way:
>
> if $x == 3 || $y == 4 {...}
>
> and
>
> if $x == 1 | 2 { ... }
>
> both DWIM. Is there a case for not doing this?
Just a thought, but don't we already have this with the "smart match"
operator?
if $x =~ (1, 2) { ... }
Or would & and | be a bit more strict in use, and thus easier for the
compiler to optimize? For instance, would we be able to:
if $x == 1 | "hello" { ... }
or would both operands have to be of the same type?
Re: perl6 operator precedence table
Or we could go with Valspeak:
$a is like $b and stuff
At the moment I like "like" the best, actually...
Hmmm... I could actually see "like" in a more active role. Along the
lines of:
my str $string;
my $other_string is like $string;
Analogous to saying:
my str $other_string
Except that it would get new type information if the type of $string is
changed at some point. Might be useful for generic classes.
class LimitedStack {
attr @.array;
my $init;
method new($first, *@others are like $first) {
$init = $first;
@.array.push($first, *@others);
}
method push(*@items are like $init) { ... }
method pop { ... }
}
Also, this brings to mind the one thing I actually remember about
Sather, and as long as we're discussing operators...
Will we have similar to Sather's "::="? That was essentially the
"statically type this variable at run-time based on the type of it's
initial value" operator.
Re: Perl6 Operator List
So many operators... It's now clear what we need. Unicode operators. That should buy us at least another week to hash out the rest of the necessary operators. ;-) It'd also silence the legions of critics who complain about Perl being too easy to read if we, for instance, used the Kanji character for watashi in place of $self, and the character(s) for anata for the default topic.
Re: plaintive whine about 'for' syntax
On Thursday, October 31, 2002, at 10:03 PM, John Siracusa wrote:
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:
Damian Conway writes:
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
but why ? I am just curious about details.
Yeah, I'd like to hear those details too, because the alternate syntax:
1) for @a -> $x ; @b -> $y { ... }
sure looks a lot more attractive and sensible to me, and I agree with
all
the arguments in favor of it so far. In particular:
* No "look here, then look there" connection between (possibly) widely
separated items.
* Simple to add or remove/comment-out individual stream/item(s) pairs
without having to "count" what are essentially positional parameters to
make
sure you haven't mis-mapped anything in the process.
* More familiar use of the semicolon (IMO)
The current syntax offers a significant advantage, though. I'm assuming
parser knows to look for equal numbers of things on both sides of
the ->. If we go with the proposed alternate syntax, won't we run into
the problem where it sees:
for @a -> $a; as a complete postfix for loop that just happens to do
nothing?
I suppose the same could be said for the existing syntax. "for @a;"
would look like a loop with the default topic variable. Maybe I'm just
wrong, but the proposed syntax seems to introduce ambiguity by breaking
the for loop up a bit too much, while the current use of the "->" and
semicolons holds the whole thing together.
As for maintaining the sanctity of the semicolon, I would offer that
consistency of the arrow operator is more important.
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 04:28 AM, Joseph F. Ryan wrote: Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members? How about something like what Ruby's irb does? % irb irb(main):001:0> class Foo irb(main):002:1>def initialize irb(main):003:2> @a, @b, @c = 1, 2, 3 irb(main):004:2>end irb(main):005:1> end nil irb(main):006:0> Foo.new # irb(main):007:0>
Re: Everything is an object.
On Thursday, December 12, 2002, at 01:11 PM, Michael Lazzaro wrote:
We can make that
@out = @in.grep({...}).map({...}).sort;# [2]
if we want to grind our OO axe, but I find that syntax disappointing.
I like that the idea is important enough in Perl to have it's own
grammar, but I realize the problem of namespace pollution involved in
having a bunch of builtins called grep, map, whatever.
The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can still
be called in a fashion similar to [1]. That would, I suspect, satisfy
everyone.
Well, if the source file were considered to be just a big giant class,
sans
class main {
...
}
then it becomes as simple as having a method in Object, grep, something
like:
class Object {
method grep($a_closure, *@input) {
...
}
}
Pike 7.4
Given discussions about "hyper" operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Automap
To perform per-element operations on arrays, there is now a convenience
syntax for map(), that can make code more readable in some situations.
Summing up two arrays element by element using automap looks like this:
a[*] + b[*]; // the result has as many elements as the shortest array.
Multiplying all elements in a by a constant:
a[*] * 4711;
Make an array of what sprintf("%O", a[n]) returns for all elements in a:
sprintf("%O", a[*]);
Re: "my int( 1..31 ) $var" ?
On Friday, January 3, 2003, at 08:55 AM, Smylers wrote: Murat Ünalan wrote: print "date" if $var is int( 1..31 ); I don't think that the type needs to be specified here, especially if the variable has already been declared to be of the required type, so a junction should be sufficient: print "date" if $var == any(1 .. 31); I was under the impression the "smart match" operator would cover that implicitly. print "date" if $var =~ 1..31; Has this changed somewhere without my noticing it? Hmmm... thinking about another form of the above, I wonder... is there a postfix version of "given"? print "date" if 1..31 given $var;
Re: "my int( 1..31 ) $var" ?
On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote: print "date" if 1..31 given $var; Except that this would always be true. Nevermind, I'm an idiot.
Re: Pike 7.4
On Tuesday, January 7, 2003, at 11:20 PM, Damian Conway wrote:
Chris Dutton wrote:
Given discussions about "hyper" operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Interesting, but I still feel that vectorized operators give more
flexibility.
For example, I'm struggling to see how one could use the [*] to do this:
@names = «Gödel Escher Bach»;
@ages = $today »-« %date_of_birth{@names}
While I agree that hyper-operators are the better way to go(though I can
see advantages either way), I was bored, so I tried to figure out a not
entirely unpleasant Perl6-ish version of the Pike syntax.
@ages[*] = $today - %date_of_birth{@names}.values[*]
Re: Array Questions
On Wednesday, January 8, 2003, at 01:32 PM, Michael Lazzaro wrote:
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve C-like behavior:
class MyArray is Array { ... };
my @a is MyArray;
Oh yes, I would certainly expect that this has to be possible.
OK, next question. Is _THIS_ possible?
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
And if _that's_ possible, is _THIS_ possible?
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Sorry, but I gotta ask. :-)
I would ask, if it's possible to inherit from Array or Hash, is it
possible to inherit from one which has a constrained storage type?
my WeirdHash is int Hash { ... }
Re: Pike 7.4
On Thursday, January 9, 2003, at 05:36 AM, Damian Conway wrote:
Chris Dutton wrote:
@ages[*] = $today - %date_of_birth{@names}.values[*]
Well done. Thanks for working that out, Chris. And, in the process,
confirming my sense that vector ops are a better solution here.
;-)
Glad I could contribute in some small way.
a thought on multiple properties
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be completely off, as I'm still digging my way
through A6):
class Foo {
method bar is public is rw {
}
}
Becoming:
class Foo {
method bar is public & rw {
}
}
Guess it just reads a bit better to me.
And you might even be able to do some weird stuff like:
class Foo {
method bar is public | rw {
}
}
Whereby bar is only an lvalue subroutine/method internally.
Re: a thought on multiple properties
On Thursday, March 13, 2003, at 02:13 PM, Jonathan Scott Duff wrote:
I don't think that junctions make sense here. Besides, the "is" is
optional:
class Foo {
method bar is public rw const frob knob { ... }
}
Ah yes, I'd forgotten about this. Thanks. Still I wonder a bit about
the idea of mutually exclusive properties, where one can take effect if
the other(s) doesn't make sense in the current context.
Getting mired in life can really detract from following the developments
in this community.
Re: A6 questions
On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
==QUESTION
- Page 8 says "In some languages, all methods are multimethods." I
believe that Java is one of these. Is that right and what are some
others? (This is really just curiousity.)
==/
Doesn't C++ work this way? Also I believe Pike allows overloading of
methods by default.
==QUESTION
- Given the following code, what is called by $ride.current_speed()?
class Vehicle {
my $speed;
method current_speed() { return $speed; }
method set_speed($n) { $speed = $n; }
}
class Car {
submethod current_speed() {
print SUPER.current_speed();
return SUPER.current_speed();
}
}
class A6 { }
my $ride = new A6;# Perl with German engineering???
$ride.set_speed(60); # Calls Vehicle.set_speed()
print $ride.current_speed(); # Calls what?
Unless this is more complicated than I think, Car's current_speed() is
called.
That said, a minor nitpick is that you'd want something more like
class Vehicle { ... }
class Car is Vehicle { ... }
class A6 is Car { ... }
