Re: Pre-PPC: class :abstract

Addendum... How this should properly work is that the design accommodates 
upgrading abstract classes and their users independently, that an abstract class 
change supports but does not require that its dependents can continue to work 
unchanged with both the older and newer versions. An example use case would be 
DBI, which is an abstract class conceptually and we can't expect every DBI 
driver to be updated in lock-sync with it. -- Darren Duncan

On 2025-12-20 2:17 p.m., Darren Duncan wrote:
> That's only dangerous if the abstract implementer makes it so. In practice, 
> default implementations with normal generic behavior would in some cases be 
> reasonable, and in cases where they are not, the default implementation could 
> throw a runtime exception, which would fail fast for users who update to the new 
> abstract class and expect to use that unimplemented feature, while not affecting 
> users who update to the new abstract class while keeping their usage unchanged. 
> -- Darren Duncan
> 
> On 2025-12-20 7:08 a.m., Ovid wrote:
>> On Sat, Dec 20, 2025 at 5:04 AM Darren Duncan wrote:
>>
>>     On 2025-12-19 2:59 a.m., Ovid wrote:
>>      > For abstract classes, they have uses, too, such as being the base class
>>     for a
>>      > factory and ensuring that every factory class has the required interface.
>>     They
>>      > do have one notable fragility, though. If you add a new abstract 
>> method, all
>>      > subclasses are immediately broken until they can be updated. Maybe not so
>>     bad
>>      > for closed source work, but bad for open source.
>>
>>     That problem is avoided easily enough by the abstract class having a default
>>     implementation, which in likely most cases would be reasonable. -- Darren 
>> Duncan
>>
>>
>> That is a very dangerous assumption. The following is a trivial example:
>>
>> use v5.40.0;
>>
>> class StorageHandler {
>>      method connect() {
>>          say "Connecting to generic backend...";
>>      }
>>
>>      # If a subclass forgets to override this, the app thinks data
>>      # is being deleted when it isn't. This violates the "fail-fast" principle.
>>      method delete_all_logs($user_id) {
>>          # Doing nothing here is dangerous.
>>          return 1;
>>      }
>> }
>>
>> class CloudStorage :isa(StorageHandler) {
>>      method connect() {
>>          say "Connecting to S3...";
>>      }
>>      # Developer forgot to implement delete_all_logs!
>> }
>>
>> my $storage = CloudStorage->new;
>> $storage->connect;
>>
>> # The dev thinks they are clearing sensitive data:
>> $storage->delete_all_logs($user_id);
>> say "Cleanup complete!"; # Oops
>>
>> -- 
>> https://curtispoe.org/ <https://curtispoe.org/>
>