[swift-evolution] #available has a huge anti-pattern.

[James Campbell]

I think if we did feature detection it should ignore private methods not
accessible by the code querying its accesbility. Additionally we really do
need proper support across platforms.

*___________________________________*

*James⎥Lead Engineer*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Wed, Feb 3, 2016 at 9:03 PM, Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Feb 3, 2016, at 1:02 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
>
> Won't it be a concern with a cross-platform Swift?
>
>
> #available is currently only implemented for Apple platforms. If someone
> wants to extend it to another platform, they need to do so in a manner that
> gives it consistent semantics.
>
> - Doug
>
>
> Félix
>
> Le 3 févr. 2016 à 15:47:15, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
>
> On Feb 3, 2016, at 5:10 AM, Jean-Daniel Dupas via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Using function availability has proven fragile in the past too. A function
> may be present but private on older system, and have a slightly different
> behavior or crash, and so should not be used.
>
>
> This is a failing of the -respondsToSelector: idiom for checking
> availability. Swift’s #available feature checks the actual OS version, so
> it doesn’t suffer from this problem.
>
> - Doug
>
>
>
> Le 2 févr. 2016 à 11:03, James Campbell via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> Coming from a web background (before my iOS career) to me #avaliable has
> huge problem. It encourages fragility.
>
> In my eyes we should encourage two types of detection: Features to make
> code more adaptable to different environments and language version
> detection: so we can understand the actual code.
>
> See this example below:
>
> func magic(object: Object)
> {
>   if(#avaliable(9.0, 10))
>  {
>   object.foo()
>  }
> }
>
> Ideally for me I would love to check if the foo function exists like so:
>
> func iOS9OnlyProtocolFunction(object: Object)
> {
>   if(#avaliable(Object.foo))
>  {
>     object.foo()
>  }
> else
> {
>   object.baz()
>  }
> }
>
> I think this encourages feature detection which results in less fragile
> code. What I would love to do is also to extend this to extensions so we
> could encourage polyfills.
>
> extend object where not_avaliable(Object.foo)
> {
>   func foo()
>  {
>    //Polyfill for platforms which don't support the Object.foo method
>  }
> }
>
> Not sure about compiler details but being able to polyfill the function
> results in much cleaner code for me. I love this approach from the web, so
> I created my own Objective-C Library to do this:
>
> https://github.com/jcampbell05/Polly
>
> *___________________________________*
>
> *James⎥Lead Engineer*
>
> *james at supmenow.com <james at supmenow.com>⎥supmenow.com
> <http://supmenow.com/>*
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/93b69441/attachment.html>