Hi Aristotle.

On 06/16/15 12:24, Aristotle Pagaltzis wrote:
* Michael Zedeler <mich...@zedeler.dk> [2015-06-16 11:35]:
This is working exactly as specified in the synopsis, but does Perl
6 NEED anything like this? Just because something is possible doesn't
make it an automatic requirement!
Well someone thought they needed it in Perl 5 so they wrote NEXT which
provides EVERY:: which does exactly the same thing. C3 dispatch surely
has something similar too, natively, I’m just not aware of it.
Which is a reasonably good argument for letting others write a *module* for Perl 6 that provides this feature. I don't see why it should be in the core.
I haven't seen just one reasonable use case for it.
Anyplace you would have to say “if you override this method then make
sure to call the overridden method also” (like calling ->new up the
inheritance tree). Instead of relying on every subclass writer to not
screw this up (and leave the object instance in an incoherent state),
you use something like these operators to make *sure* a certain method
is called all up the inheritance tree as necessary for your de-/init
needs.
Sorry. Doesn't make sense.

class A {
    sub destroy {
        ...important cleanup....
    }
}

class B is A {
    sub destroy {
        ...important cleanup...
        nextall;
    }
}

followed by

$b.destroy

What is it that make this *less* preferable over

class A {
    sub destroy {
        ...important cleanup....
    }
}

class B is A {
    sub destroy {
        ...important cleanup...
    }
}

$b.+destroy.

The latter breaks encapsulation. The subclass B has the *full* responsibility to handle the method call. Not the caller.
Every modern Perl 5 OO system invents stuff like BUILD and DEMOLISH for
this purpose. And one of the points of Perl 6 is not to have to handroll
a reasonable OO system as your first step in writing nontrivial systems.
So putting these operators right in the language, properly designed, is
specifically called for.
Show me the precedence for constructs like this in other languages, please. I haven't seen any and I belive it is because they're not necessary.
Just because you can’t think of the use of a feature doesn’t mean there
isn’t one.
Of course. That's why I've brought up the subject for discussion here.
Or maybe you are aware of the motivation for these designs and disagree
with that desire in the first place? In that case I don’t know what to
say; obviously there are plenty of people who do see it as a necessity.
I am really not so sure, because I've tried to bring up the subject a couple of times, and every time I get answers from people like you: people who don't need the feature themselves, but refer to it as something someone else probably need. Please show me an example that makes Perl 6 vastly more useful by the addition of this feature.

Perl 6 could be great because things like this operator could be deferred to non-core modules, but right now they're in the core and nobody can really explain why. *COUGH* featurecreep *COUGH*

Regards,

Michael.

--
Michael Zedeler
70 25 19 99
mich...@zedeler.dk

dk.linkedin.com/in/mzedeler | twitter.com/mzedeler | github.com/mzedeler

Reply via email to