[swift-evolution] #available has a huge anti-pattern.
Zach Waldowski
zach at waldowski.me
Wed Feb 3 15:20:10 CST 2016
Joe —
Is this intended to be a supported behavior? I was all excited the other
day to discover this behavior, using it to backport iOS 9's
NSLayoutConstraint DSL. It mostly works, but as soon as an expression
gets relatively complex (array literals >5 or so) or has any sort of
error in it, Swift falls back to reporting an availability error.
Zach Waldowski zach at waldowski.me
On Tue, Feb 2, 2016, at 11:26 AM, Joe Groff via swift-evolution wrote:
> Polyfills have their own tradeoffs; they tend to encourage constant
> accretion of glue code as new versions get added if there's no
> pressure to drop old versions, leading to a significant amount of the
> multi-megabyte Javascript framework downloads we all complain about
> these days. That said, you might be able to use the related
> `@available` attribute to introduce backfill extensions that are only
> available on older systems.
>
> -Joe
>
>> On Feb 2, 2016, at 2:03 AM, James Campbell via swift-evolution <swift-
>> evolution at swift.org> wrote:
>>
>> 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⎥supmenow.com[1]*
>> *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
Links:
1. http://supmenow.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/6bbe5dc5/attachment.html>
More information about the swift-evolution
mailing list