This spec subtly alters the meaning of "...". Whereas "yada" used to
mean "this is not yet implemented, complain if executed" it now adds
"but don't complain if it is a class fully implemented elsewhere".
Allowing two implementations of a class iff one of them has a yada
opens up maintenance issues. There's "action at a distance", when
reading the source looking for the definition of "class Foo"- the
reader could be looking at one and not seeing the other. Editors and
code refactoring gets more complicated. It's too easy for two people
to edit the different "class Foo"s without realizing there are two,
especially if they leave the "yada" in place in anticipation of
further editing & reviewing.
Also this spec leaves some cases unspecc'ed. Does it matter which
order the "yada" class and "complete" class are compiled, or if there
are many "yada" classes? Do any of the definitions in the "yada" class
carry over into the "complete" class?
Does the same rule hold for methods, subs, all other named blocks, so
we can put a "yada" in one to pseudo-comment it out?
-y
On Sun, Sep 6, 2009 at 11:48 PM, <pugs-comm...@feather.perl6.nl> wrote:
> Author: moritz
> Date: 2009-09-07 08:48:34 +0200 (Mon, 07 Sep 2009)
> New Revision: 28196
>
> Modified:
> docs/Perl6/Spec/S12-objects.pod
> Log:
> [S12] spec behaviour of stubbed classes
>
> This is a bit more general than what I had in mind first. If the implementors
> say this is too hard to do it this way, we can degrade it to allow only a
> single
> '...' term in the body of a stubbed class.
>
> Modified: docs/Perl6/Spec/S12-objects.pod
> ===================================================================
> --- docs/Perl6/Spec/S12-objects.pod 2009-09-06 15:06:11 UTC (rev 28195)
> +++ docs/Perl6/Spec/S12-objects.pod 2009-09-07 06:48:34 UTC (rev 28196)
> @@ -55,6 +55,22 @@
> class is also a module, it also handles any module-oriented keywords.
> You can export subs from a class at "use" time, for instance.)
>
> +If the class body throws an exception from a literal C<...> (yada) term,
> +the class defintion is considered incomplete, and a second definition of
> +that class does not complain, so you can write
> +
> + class Foo {
> + has $!some_attr;
> +
> + ... # literal ... here interrrupts class definition
> + }
> +
> + # other code here
> +
> + class Foo {
> + # rest of class defintion here
> + }
> +
> A named class declaration can occur as part of an expression, just like
> named subroutine declarations.
>
>
>
