+1 On Monday, 21 March 2016, Tino Heth via swift-evolution < [email protected]> 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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
