> On Dec 29, 2015, at 5:45 PM, Charles Srstka <cocoa...@charlessoft.com> wrote:
>
> On Dec 29, 2015, at 5:38 PM, Matthew Johnson <matt...@anandabits.com
> <mailto:matt...@anandabits.com>> wrote:
>>
>>
>>> On Dec 29, 2015, at 5:25 PM, Charles Srstka <cocoa...@charlessoft.com
>>> <mailto:cocoa...@charlessoft.com>> wrote:
>>>
>>> Strong +1 on this proposal. I use Objective-C’s forwarding mechanisms quite
>>> often in my custom view code, in order to separate the code managing the
>>> outer view, the layout of subviews within the view, and business logic into
>>> separate classes, all while presenting a single, monolithic interface to
>>> the user. The loss of this ability without writing tons of boilerplate is
>>> one of the things about Swift that makes me sad.
>>>
>>> The one thing I’d change is upgrading the partial forwarding synthesis to
>>> the original proposal, as that’s a rather important feature IMO.
>>>
>>
>> Thanks Charles. Do you disagree with the reasons I decided not to include
>> partial forwarding in the initial proposal (it is discussed in alternatives
>> considered)?
>
> I see it in Future Enhancements, but not in Alternatives Considered (unless
> I’m just missing it). However, my thinking is that this isn’t really that
> hard to implement; just have the forwarding mechanism forward only methods
> that aren’t already implemented in the class. This would be similar to the
> way protocol extensions work, where if you implement the method you get that,
> but if you don’t implement it, you get the protocol extension’s
> implementation.
>
You are right, I included it in that section. It is definitely something I
want to see supported eventually. I just don’t want it to hold up the initial
proposal.
I also want to make sure any subtleties have been thoroughly considered and
addressed before it goes forward. I understand that it is in some sense
similar in some sense to protocol methods with default implementations.
However I think it is actually closer to inheritance (this proposal can in some
respects be considered a limited and controlled form of multiple inheritance).
The author of a protocol understands and intends the default implementations to
be just that - defaults. The author of the type that is forwarded to may have
expectations that it receives all calls for all members of a protocol it
implements and the implementation may not work correctly or as expected if that
does not happen. IMO, it is important to think about the implications of
partial forwarding, limitations that may be necessary, etc.
Despite my caution around partial forwarding, there is one reason that it might
make sense to support partial forwarding in the initial proposal.
Specifically, it would be easy to get around the limitation by simply declaring
a new protocol that contains only the members you want to forward and use that
in your forwarding declaration. And of course you can also write manual
forwarding code. So a limitation of the automatic forwarding mechanism
wouldn’t stop you from doing partial forwarding, it would just make it more
annoying. It might be better to “complete” the design from the start for this
reason. I will definitely give this further thought.
Do you have specific use cases in mind for partial forwarding? If so, please
share them.
Matthew
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
