[swift-evolution] struct subtyping

[Howard Lovatt]

+1

On Monday, 21 March 2016, Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

> Many languages which adopt the concept of value types don't allow
> subclassing for those, and so does Swift.
> Inheritance for structs is more complex than inheritance for classes, but
> the "final" limitation isn't the only possible solution, and Dave Abrahams
> told me in another thread that changing this rule might be considered in
> the future — so I'll risk getting taunted by the cool kids who are in favor
> of eliminating all ancient OOP-ideas ;-) and start a discussion.
>
> I guess most readers know about the low-level problems that arise when we
> switch from pointers (always the same size) to value types (size may vary),
> so I'll start with two possibilities for struct subtyping:
>
> *newtype* (see https://www.haskell.org/tutorial/moretypes.html — or just
> read on if you are scared by Haskell ;-)
>
> When a subtype does not add any stored properties to its superclass
> (memory layout doesn't change), there is no difference at the level of
> object code — only the type checker may stop you from using those two types
> interchangeably.
> Some use cases:
> - In Cocoa, there is no separate class for (file system) paths; instead,
> there are some additions to NSString. String doesn't have those abilities,
> and imho methods like "stringByAppendingPathExtension" deserve a separate
> Path-struct, so that those special methods don't pollute the method list of
> String (URL is the future, so that example is somewhat out-of date).
> - You could impose incompatibility on numeric types to ensure that your
> calculations use correct quantities. Although this can be annoying (Float
> vs. CGFloat), decorating numbers with quantity/unit could eliminate bugs
> that had really disastrous consequences in the past.
> - Increased comfort for floating-point math:
> struct CustomDouble: Double
>
> func == (a: CustomDouble, b: CustomDouble) -> Bool {
> return abs(a.value - b.value) < 0.01
> }
> (no need to specify tolerance for each comparison)
>
> *Full subtyping*
>
> As long as you don't cross module borders, it wouldn't be that complicated
> to add inheritance without restrictions.
> imagine you have a "Customer"-type and a "Employee"-type to store personal
> data (name, address…).
> Those data objects are perfect candidates to be implemented as structs,
> but they also cry for a "Person"-superclass, so you are forced to either
> duplicate code, or to implement your objects as reference types.
>
> In a real proposal, I would include more details on the problems caused by
> this feature, but I'd like to see some feedback first.
>
> Best regards,
> Tino
>


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