[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Leonardo Pessoa]

Matthew, I also thought that way but I think there is no harm in
allowing one to create a subclass if there are no open methods in it,
meaning there is no way a subclass can even replace an existing
implementation. Even if Swift were to allow creating a new method with
the same name of an existing superclass method the new method should
not respond for calls made using the superclass as base. This is
allowed in C# where you can have the following (*dusts off*):

   class A {
      public virtual void method() {
          Console.println("method in A");
      }
   }

   class B : A {
       public final void method() {
          Console.println("method in B");
      }
   }

   class C : B {
       public new void method() {
          Console.println("method in C");
       }
   }

   B b = new C();
   b.method(); // prints "method in B"
   C c = (C) b;
   c.method(); // prints "method in C"

I know I'm being a little flexible here given my previous messages to
this list but if we are to allow subclasses to be openly created,
subclasses will only be allowed to implement new interfaces and create
new methods but not mess with the base implementation unless a method
is explicitly open, there is no harm to the defined contract, so I see
no harm in this approach for composition.

And yes, contracts are about (at least some) control.

L


On 21 July 2016 at 15:08, Matthew Johnson via swift-evolution
<swift-evolution at swift.org> wrote:
>
>> On Jul 21, 2016, at 12:47 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>> on Thu Jul 21 2016, Matthew Johnson <swift-evolution at swift.org> wrote:
>>
>>>>     * What is your evaluation of the proposal?
>>>
>>> +1 to the first design.  I think this is a great solution that
>>> balances the many considerations that have been raised on all sides of
>>> this issue.  `open` is 2 characters shorter than `public` so
>>> complaints about boilerplate are no longer valid.  `internal` is the
>>> “default” - neither `public` nor `open` are privileged as a “default”
>>> for publishing API outside of a module.
>>>
>>> I am interested in language enhancements such as exhaustive pattern
>>> matching on classes and protocols which rely on knowledge of the full
>>> class hierarchy.  Such enhancements will be far more useful if the
>>> language supports non-open, non-final classes.
>>>
>>> There are design techniques that would require additional boilerplate
>>> if we cannot have non-open, non-final classes.
>>>
>>> Most importantly, requiring library authors to choose `public` or
>>> `open` provides important documentation value.  Users of the library
>>> will know whether the author intends to support subclasses or not.
>>
>> I think this reasoning is flawed.
>>
>> If you make any methods overridable outside your module (“open”),
>> obviously you mean to allow subclassing outside the module.  If you have
>> no open methods, there's absolutely nothing you need to do to “support
>> subclasses,” and from a design point-of-view, there's no reason to
>> restrict people from subclassing.
>
> I disagree.  As has been discussed when a class is not open the author does not make a commitment to allow subclasses.  The right to make the class final is reserved for the future.  Maybe this is the “nice point of control” you refer to and don’t find compelling?  I would prefer to have library authors acknowledge that they intend to allow subclasses and make that commitment explicit.
>
> For me it isn’t about control as much as it is about making the API contract explicit and acknowledged.  I have wondered about the intent of library authors enough times to find this explicit statement in the language worthwhile.
>
> I also think language features enabled by knowing the whole class hierarchy will provide more value than “compositional subclasses” as long as we gain better support for composition elsewhere in the language.
>
>>
>> The only reasons I can see for allowing people to prevent non-final
>> classes from being subclassed outside the module in which they are
>> defined are:
>>
>> 1. It feels like a nice point of control to have.
>>
>> 2. Marginal performance gains as noted in the proposal
>>
>> I personally don't find these to be convincing.  #1 in particular seems
>> like a poor way to make language design decisions.  If we decide to add
>> this point of control, I'll justify it to myself in terms of #2.
>>
>> P.S., I can live with either alternative; it's just important to me that
>> we understand the situation clearly when evaluating them.
>
> I agree with this.
>
>>
>> HTH,
>>
>> --
>> Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution