Re^2: Perl OOP

1. No, because that's a terrible idea. If I've created a class, why shouldn't you be able to inherit from it?

Because it may not be safe to do so, e.g. from Method Privacy in Perl

Recently I was writing a subclass of somebody else's class and noticed it suddenly started behaving strangely. After an embarrassing amount of time spent debugging I discovered that one of my underscore methods happened to have the same name as one of the superclass' underscore methods (actually two levels up inheritance), so was getting called by the superclass when I hadn't expected it to be.

Whereas a construct for disallowing inheritance (on a per class basis) would make it clear to a would be subclasser that the class wasn't designed for inheritance.

But the OP was asking about how (as an author) they can stop their classes from being subclassed. I think this is totally legitimate from a design point of view given all the design warts of inheritance:

introduces tight coupling
breaks encapsulation
increases cognitive load

Comment on Re^2: Perl OOP

Replies are listed 'Best First'.
Re^3: Perl OOP by tobyink (Canon) on Jul 05, 2017 at 17:07 UTC
But the OP was asking about how (as an author) they can stop their classes from being subclassed. I think this is totally legitimate from a design point of view I think it's as legitimate as asking how I, as a car manufacturer, can stop the people who buy my cars from hanging fuzzy dice from the rear-view mirror. Or how I can stop them from keeping their muddy boots on the back seat. It's none of my damn business. If I don't want them doing that, I shouldn't sell the car. If I really need the sale, but still don't want them doing it, I can document that it voids the warranty for their expensive leather seats.	[reply]
Re^4: Perl OOP by Arunbear (Prior) on Jul 06, 2017 at 16:56 UTC
You're confusing the regular use of an object (which no one is arguing against) with modular design of an object (to use inheritance or not). The analogy you gave would be relevant to this discussion if it had any semblance to design by inheritance, but it doesn't. But staying in the realm of car manufacture, we build cars by composing them out of components. Let's say you want to build (using 'inheritance') a new SmartLandRover that has additional sensors to detect when the driver is drunk, but 'inherits' other functionality from a base model Land Rover. SmartLandRover doesn't have a battery, so it must have wires connecting it to BaseLandRover so it can get power. SmartLandRover also doesn't have an engine, so it must have a shaft connecting it to the drive shaft of BaseLandRover so it can get movement. This may seem ridiculous, but we do something quite similar when we use inheritance. No one designs or builds cars like that, and with good reason.	[reply]
Re^5: Perl OOP by pryrt (Abbot) on Jul 06, 2017 at 18:04 UTC
I like your LandRover analogy. In that system, my interpretation of the spirit of tobyink's analogy becomes: I buy a `LandRover`, and want to create a `LandRover::PryrtMod`, wherein I plug in an OBDII unit into the standard OBDII slot of my LandRover, so that I can look at some of the sensor data that they don't provide using my smartphone app. Or similarly, years ago, I bought a `Mazda::RX8 v2005`; in the intervening time, backup cameras became the norm on newer cars, so I bought an aftermarket backup camera, and created the `Mazda::RX8::PryrtBackupMod` which inherited the full `Mazda::RX8` object, but just added the callback `Mazda::RX8::PryrtBackupMod::enableBackupCam()`, and I registered that callback for use inside `Mazda::RX8::changeGear()`. I understood when I made `Mazda::RX8::PryrtBackupMod` that it could possibly void any warranty, but I was able to weigh the risks vs. benefits and make an informed engineering decision. Mazda, as the manufacturer, can discourage people from trying to subclass their vehicles, and can void warranties if their product is inappropriately modified; but at some point, car hackers will find a way to subclass a vehicle with aftermarket modifications. Similarly, a Perl hacker will often be able to figure out how to subclass and add functionality to your "immutable object" class.	[reply] [d/l] [select]


There's more than one way to do things
	PerlMonks