* Michael Zedeler <mich...@zedeler.dk> [2015-06-16 13:10]:
> 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.
Because it’s terrible in the out-of-core form on CPAN?
>>> 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.
I’m not sure why you thought that when I say it’s broken to give the
subclass this responsibility, it follows that I mean that the *caller*
should be responsible, which is so much more broken that… well, that it
was obvious even to you.
No, the *superclass* ought to take responsibility here:
class A {
method teardown { $self.+TEARDOWN }
method TEARDOWN { ... }
}
class B is A {
method TEARDOWN { ... }
}
class C is B {
...
}
$c.teardown
Not only does that not break encapsulation at the caller, it also keeps
the responsibility encapsulated from subclasses. They just need to take
care of their own cleanup, they need not make sure everyone else’s gets
called too.
That’s what it’s useful for: to provide a contract of this type in one
place in a superclass (or maybe a role or some other single authority).
(It doesn’t even have to be provided at the root of the hierarchy.)
> > 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.
Mostly because they make `new` an operator or otherwise have special
cases for e.g. instance construction and destruction, such that you
don’t need to do this in the most common case (same as you won’t in
Perl 6)… but nor *can* you in most languages, if you happen to have
a less common use case.
> > 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.
Is that what kind of people I am?
I thought I had needed and used EVERY::LAST:: in Object::Properties.
> Please show me an example that makes Perl 6 vastly more useful by the
> addition of this feature.
No. I have already mentioned BUILD/DEMOLISH and explained the motivation
in text. You did not appear to even realise that those were examples of
the use case, nor appreciate their usefulness (and not just to people
other than me).
I am willing to help you appreciate the use of this feature but I have
no interest convincing you that it is a good idea. If you do not have
the curiosity to take my answer seriously, there’s nothing left to do.
> 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*
Pardon me for not quite believing that you think Perl 6 would be AMAZING
except alas, it has this .* / .+ operator that ruins EVERYTHING. So the
question is, do you actually think Perl 6 could be great or do you just
wish you could pluck a few of its features into the comfort zone of some
other familiar language?
Maybe you do think Perl 6 could be great. If you have thoughts on how
its design fits together and what about it could and maybe ought to be
different, that would be an interesting conversation to have. Picking
out some niche feature at random and coughing feature creep isn’t.
(That these operators are a niche feature and ought not make a lot of
appearances is true. Maybe they ought to be dehuffmanized relative to
their current form. But that too is a different conversation from the
one we’re having (and, again, an actually interesting one, as it gets
into actual design choices).)
In any case, you are under no obligation to like it, you know.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
