[swift-evolution] Follow up: overridable members in extension

[Technical Rossetti]

This is in reference to:

 swift-evolution/nnnn-overridable-members-in-extensions.md at overridable-members-in-extensions · jrose-apple/swift-evolution · GitHub <https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md>

The limitation of not being able to override methods introduced by an extension to a parent class within a child class is pretty significant and I would propose that we find and explore a way to allow such while supporting the original intent of this limitation.

This has become a problem for a project I’m working on when transitioning to Swift 4. Here is a description of the problem:

Our major application has a class hierarchy of financial transaction types similar to the following:

Transaction
Billable
	Taxable
		Purchase
			Bill
			...
		Sales
			Estimate
			Invoice
			...
Deposit
Journal Entry
...

Etc.

These are currently implemented in ObjC but have been extended in Swift. So there are the original transaction classes in ObjC with extensions in Swift. 

This combination of ObjC/Swift has been done to support modern presentation in iOS, essentially following the MVVM approach. ‘Transaction’ has been extended and specifies the various View Model methods each of its child classes must implement. There are default implementations going down the Swift inheritance tree but each child can customize (override) those methods and, many times, calls the inherited method.

For instance, the header presentation for each transaction shows a date and total amount but each subclass has other header elements to show: all ‘Billable’ transactions show a name and due date. Going down the chain, each final child class provides the explicit title to be shown in the header, such as ‘Invoice’. Further, the background color of the header is set based on the status of the transaction. Of course, some transactions only have one state, the default state provided by a parent class.

With this said, eliminating the ability to extend ‘Transaction’ and then override down in each subclass’s extension was very convenient. Under the current Swift 4 restrictions we will have to either reimplement the class extensions in the original model (which will not be done because the model must be ignorant of any presentation-specific requirements) or everything will have to be moved up into a single Transaction extension and use a switch structure based on dynamic casting as discussed in the article mentioned way above (which corrupts ‘Transaction’ by requiring it to know intimate details about its children, grandchildren, etc.).

It would be nice if there were some protocol-based mechanism where a parent class could adopt that protocol (not in the original class declaration, of course, since UI-related methods should not be polluting the model layer) and then some extension-like mechanism allowing child classes to provide their specific implementation of those methods.

Of course, one potential approach would be to create a similar class structure to the model’s Transaction structure but where the new class ‘owns’ the instance of the raw transaction. Say, something like TransactionVM with BillableVM, PurchaseVM, etc. Of course, for each different type of transaction presentation (full details, brief details, list summary, etc.) there would need to be yet another ‘container’ class structure. And they wouldn’t be able to inherit from one another for the same reason I’m blathering on here.

Of course, if there is already a more appropriate approach for solving a problem like this, please do not hesitate to correct me as I still consider myself pretty ‘young’ with Swift 4.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170919/fef03704/attachment.html>