<div dir="ltr">+1 to sealed<div>+1 to sealed-as-default.</div><div><br></div><div>I prefer the need to explicitly share details that I would like to share. Separately, I do think that we need to improve the tools for auditing and organizing APIs. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 2, 2016 at 8:35 AM, L. Mihalkovic via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Inline<br>
Regards<br>
(From mobile)<br>
<div><div class="h5"><br>
On Jul 2, 2016, at 10:51 AM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br>
<br>
>> On Jul 2, 2016, at 12:42 AM, L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com">laurent.mihalkovic@gmail.com</a>> wrote:<br>
>><br>
>> This is a situation I often run into in jave where I would use an enum to create a finite set of constants to be passed (say action identifers). But then this makes it very difficult for external modules to extend the core set of actions locally. So i generally windup with an enum and an interface (the enum implements the interface).<br>
><br>
> Sure. I would argue that that's the exact right approach to take for this kind of thing. For instance, for storyboard segue identifiers, I would write something like this:<br>
><br>
> open protocol SegueIdentifierProtocol: RawRepresentable where RawValue == String {}<br>
><br>
> open protocol SeguePerformable {<br>
> associatedtype SegueIdentifier: SegueIdentifierProtocol<br>
><br>
> // Hooks<br>
> func shouldPerformSegue(with identifier: SegueIdentifier, sender: AnyObject?) -> Bool<br>
> func prepare(for segue: UIStoryboardSegue, with identifier: SegueIdentifier, sender: AnyObject?)<br>
> }<br>
><br>
> public extension SeguePerformable where Self: UIViewController {<br>
> // Machinery to bridge to normal UIViewController API<br>
><br>
> func performSegue(with identifier: SegueIdentifier, sender: AnyObject?) {...}<br>
> override func shouldPerformSegue(withIdentifier identifier: String, sender: AnyObject?) -> Bool {...}<br>
> override func prepare(for segue: UIStoryboardSegue, sender: AnyObject?) {...}<br>
> }<br>
><br>
> Rather than attempting some sort of universal enum of all identifiers:<br>
><br>
> extension UIViewController {<br>
> open enum SegueIdentifier: String {<br>
> // Extensible for users<br>
> }<br>
><br>
> // Hooks<br>
> open func shouldPerformSegue(with identifier: SegueIdentifier, sender: AnyObject?) -> Bool {...}<br>
> open func prepare(for segue: UIStoryboardSegue, with identifier: SegueIdentifier, sender: AnyObject?) {...}<br>
><br>
> // Machinery to bridge to normal UIViewController API<br>
> public func performSegue(with identifier: SegueIdentifier, sender: AnyObject?) {...}<br>
> override public func shouldPerformSegue(withIdentifier identifier: String, sender: AnyObject?) -> Bool {...}<br>
> override public func prepare(for segue: UIStoryboardSegue, sender: AnyObject?) {...}<br>
> }<br>
><br>
>> Then local extensions are free to define their own local enums to cover only their local extensions to the original core set of actions. Then the public api definition constrains the action parameter to be enum&TheRequiredInterface.<br>
><br>
> Okay, but why constrain it to `enum`? Do you actually care that it's an `enum`, or do you just care that there's a type which can give you the identifier you need? If somebody wrote a highly dynamic client of your code that needed to generate identifiers on the fly, why should your code reject that?<br>
<br>
</div></div>In the case of a segway id (i did watch the wwdc presentation last year too) the protocol representation is IMHO more a pedentic exercise in 'look how pretty i can make my code' than an actual technical necessity (considering people have been writing the same apps in objc for years, their argument of 'avoiding mismatch' did not hold much water when considering the scale we are talking about).<br>
<br>
I was refering to real life systems (think state machine-like libraries for eg) where having access to the complete set carries a real value. For some, dealing with multiple disjointed sets is a minor hickup, for others a real feature. The point is i am describing carefully designed real life (many trading) systems for which i truly care about every piece of what i described for various reasons (be it size/modularity 400KLOC+ systems, bytecode level efficiency of enums as Hash keys, .... ). At this point none of these systems could be done in swift yet due to small gaps here and there (of course they could technically be rewritten in cobol if need be, but at a tremendous loss):<br>
* can't constrain on enum (what's worse is Dave is not even convinced there is any case for it)<br>
* can't easily discover all cases<br>
* can't annotate enum case with meta information making runtime adaptation possible<br>
...<br>
<br>
Maybe the gap will never close and java/scala/kotlin/ceylon will remain the languages of choice for the real life servers of this world. An interesting question might be: what to do when a phonegap app written in typescript is much more expressive than its swift counterpart? Today i use swift because it is new and fun, but i find c# much more powerful for even iOS only apps. But i have high hopes.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>