>> On 2015/03/11, at 14:44, Quincey Morris
>> <quinceymor...@rivergatesoftware.com> wrote:
>>
>> On Mar 10, 2015, at 22:26 , Bavarious <bavari...@icloud.com> wrote:
>>
>> Much like in Objective-C. If you write
>>
>> void someFunction(id obj) {
>> NSLog(@"%@", [obj bundleURL]);
>> }
>>
>> the compiler picks *some* method that matches that selector
>
> So how come this behavior has been imported into Swift? What problems does
> having it there actually solve? Other languages are going to laugh at us and
> take our lunch money if we have types like ‘NSURL!?’.
>
>> ―which method is undefined. This can be problematic when multiple methods
>> have the same selector but different types; in particular, when one method
>> has a floating-point type in its signature and another method doesn’t.
>
> That’s what I don’t understand for Swift. None of the reasons I can imagine
> for *not* removing this behavior from Obj-C** seem applicable to Swift.
This is simply part of the evolving state of affairs.
For now, this is part of life if you use Swift and you use objects that inherit
from NSObject.
There's an impedance mismatch ever so small but annoying.
Swift hates nil or potentially nil and wants to know if something is expected
to potentially be nil.
Objective-C and Cocoa built loads of incredible clever patterns with nil.
This is one extra thing you have to really get used to with Swift. You learn
Swift, then learn that it effectively requires some constant special handling
for NSObject's descendants.
If you're using the frameworks that's a lot of optionals and implicitly
unwrapped optionals.
>
> ** such as:
>
> #1: Historical precedent (Swift is all-new source code)
> #2: Ugly cast syntax to clarify which selector is intended (Swift has ‘as!’)
> #3: Obscures full-on polymorphism (rarely used in many classes of apps, more
> common usage of limited polymorphism is better expressed via protocols, which
> are more capable in Swift)
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dangerwillrobinsondanger%40gmail.com
>
> This email sent to dangerwillrobinsondan...@gmail.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
