[swift-evolution] #available has a huge anti-pattern.
Félix Cloutier
felixcca at yahoo.ca
Wed Feb 3 15:02:02 CST 2016
Won't it be a concern with a cross-platform Swift?
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 <mailto: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 <mailto: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 <https://github.com/jcampbell05/Polly>
>>> ___________________________________
>>>
>>> James⎥Lead Engineer
>>>
>>> james at supmenow.com <mailto: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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/75569d6f/attachment.html>
More information about the swift-evolution
mailing list