> ==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?
>
> [NB: an A6 is a type of car made by Audi; I couldn't resist.]
> ==/
Assuming the obvious inheritance, Vehicle.set_speed() would be called.
> ==QUESTION
> - On page 9, on the section concerning Rules, we see the following
> quote:
>
> "They [rules and methods] share the same namespace, and a rule
> really is just a method with a funny syntax."
>
> If that's so, why does there need to be a distinction between them?
> Wouldn't it be better to use up as little mind-space as possible,
> and reduce the required syntax set, by eliminating rules as a
> separate type?
> ==/
No. Rules fit better in a grammar than subs, and help the psychology
of people in various ways. For instance:
multi subst(Str $str: Rule $match, Code $repl) { ... }
Helps people to know that $match should be a regex. Helps the
compiler, too.
Also, it looks nicer:
sub identifier {m{ <[\w]-[\d]> \w+ }}
rule identifier { <[\w]-[\d]> \w }
> ==QUESTION
> - Also on page 9, concerning macros:
>
> "...while a macro's name may be installed in either a package
> or a lexical scope, its syntactic effect can only be lexical,
> from the point of declaration (or importation) to the end of
> the current lexical scope."
>
> Does that mean that I cannot define a bunch of commonly-used macros
> in a single file and then use them in different files?
> ==/
I think he talked about this in an appendix. You can export them, if
I recall.
>
> ====QUESTION
> - SUPER:: is mentioned on page 9. Was this an analogy, or a
> demonstration of intention to keep it?
> ==/
I think there was intention to keep it. It's a useful thing, you
know.
> ====QUESTION
> - Regarding <== and ==>:
>
> list(@foo, how => 'scrambled' <== 1,2,3)
>
> I had to read this a bunch of times before it started to make any
> sense. What is happening here is that the 1,2,3 to the right of <==
> constructs a list, and the list(...) constructs a list of everything
> inside it. So a list is made of the 1,2,3, and that list is then
> appended (via the pipe) to the list being built by the list(...). Is
> that correct? And doesn't it meant that the <== is redundant and
> obfuscatory?
I'm not too happy with the semantics of ==> and <==, but they might
grow on me... we'll see. Anyway, yes it is redundant. Just as
postfix C<if> is redundant with C<and>. It's still a useful thing to
have, in terms of readability.
And like most things in Perl, it can also be obfuscatory, given the
proper guise.
Luke
