[swift-users] Possible swift 3 method rewrite issue with NSRequestConcreteImplementation ?

[John Spurlock]

Nope, that doesn't work, try it yourself.

I tried that, any many more variations, before posting the minimal repro
example here.

On Thu, Jul 21, 2016 at 5:46 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> I’m a bit late here, but I don’t see why this is necessary. John overrode
> 'encode(_: Int, forKey: String)’ instead of ‘encode(_: Int32, forKey:
> String)’. Sure, overloading makes this kind of mistake harder to spot,
> especially when the run-time error comes from Objective-C, but it’s hardly
> unusual for a Swifty program.
>
> Jordan
>
>
> On Jul 21, 2016, at 13:06, Tony Parker via swift-users <
> swift-users at swift.org> wrote:
>
> FYI:
>
> https://github.com/apple/swift/pull/3663
>
> - Tony
>
> On Jul 20, 2016, at 12:10 PM, Tony Parker via swift-users <
> swift-users at swift.org> wrote:
>
>
> On Jul 20, 2016, at 5:17 AM, John Spurlock <john.spurlock at gmail.com>
> wrote:
>
> 1. Since encoding/decoding various types is the principal domain of this
> type, it seems ok to be overly clear in the method names here.
>
>
> Agreed; I’m trying out a few approaches to see what works best.
>
> 2. Is there a way to systematically look for other types that may also
> have this problem lurking with ints or other similar overload groups?
>
>
> I don’t think so. I also know that the importer will happily create
> ambiguous method names, for example when importing two ObjC methods that
> are the same except that one has an options argument. The options gets a
> default value and presto - two methods with the same signature. We only
> find out when someone tries to use it in other source code.
>
> - Tony
>
> On Tue, Jul 19, 2016 at 9:52 PM, Tony Parker <anthony.parker at apple.com>
> wrote:
>
>> I thought of the exact same name, but I'm not enthusiastic about the
>> inconsistency this creates with all of the other decode methods on NSCoder.
>> I'm discussing with a few people to decide what to do next.
>>
>> - Tony
>>
>> On Jul 19, 2016, at 6:32 PM, Brent Royal-Gordon <brent at architechies.com>
>> wrote:
>>
>> You could just do the one and call it encodeCInt. I think people would
>> understand that it's different because it's using a sort-of-foreign type.
>>
>> --
>> Brent Royal-Gordon
>> Sent from my iPhone
>>
>> On Jul 19, 2016, at 4:33 PM, Tony Parker <anthony.parker at apple.com>
>> wrote:
>>
>> Hi John,
>>
>> Thanks for filing the bug.
>>
>> The root cause of the issue is that the importer would turn the following
>> methods into the same name:
>>
>> - (void)encodeInt:(int)x forKey:(NSString *)k;
>> - (void)encodeInt32:(uint32_t)x forKey:(NSString *)k;
>>
>> Plus, there is the added confusion that this method:
>>
>> - (void)encodeInteger:(NSInteger)x forKey:(NSString *)k;
>>
>> is imported into Swift like this:
>>
>> func encode(_ x: Int, forKey k : String)
>>
>> where, as you can see, “Int” means “NSInteger”, but not the C “int”.
>>
>> I’m not really sure how to resolve this and still allow for subclassing
>> without simply reverting these names back to Swift 2.2 style, so I think
>> that’s probably what I’ll have to do:
>>
>> func encodeInt(_ x : Int32, forKey k : String)
>> func encodeInt32(_ x : Int32, forKey k : String)
>> func encodeInt64(_ x : Int64, forKey k : String)
>> func encodeInteger(_ x : Int, forKey k : String)
>>
>> and so on, for all of the encode methods, so they are consistent.
>>
>> - Tony
>>
>> On Jul 19, 2016, at 8:20 AM, John Spurlock <john.spurlock at gmail.com>
>> wrote:
>>
>> Ok, filed a new bug for the encodeInt:forKey issue:
>> rdar://problem/27425997
>>
>> Ensured it reproduces in xcode beta 3, swift version 3.0
>> (swiftlang-800.0.34.6 clang-800.0.33)
>>
>> Is there anything I can do in the meantime as a swift-only workaround to
>> fix my custom NSCoder?
>>
>> Thanks,
>> - john
>>
>> On Mon, Jul 18, 2016 at 10:52 PM, Tony Parker <anthony.parker at apple.com>
>> wrote:
>>
>>> We renamed some of these methods for Swift 3 in an attempt to remove
>>> some of the confusion surrounding which of these did what - they were
>>> really named for C types and not Swift ones.
>>>
>>> encodeInt:forKey: and decodeInt:forKey: are the two missing ones, since
>>> they were easily confused with the Swift Int type. I think we’ll have to
>>> figure out a different approach here. John, please file a bug at
>>> bugreport.apple.com and let me know the radar number, and we’ll look
>>> into it.
>>>
>>> Thanks,
>>> - Tony
>>>
>>> > On Jul 18, 2016, at 6:33 PM, Brent Royal-Gordon <
>>> brent at architechies.com> wrote:
>>> >
>>> >> Hi Tony - when I add that attribute, I get an error at compile-time:
>>> >> Objective-C method has a different selector from the method it
>>> overrides ('encodeInt:forKey:' vs. 'encodeInteger:forKey:')
>>> >>
>>> >> If I update to encodeInteger:forKey as the fix describes, it
>>> compiles, but I'm getting the same original problem at runtime.  i.e.
>>> "encodeInt:forKey: only defined for abstract class"
>>> >>
>>> >> Any other ideas?  See the same thing over there?  You should be able
>>> to paste that into a new swift 3 test.
>>> >
>>> > If you look at the NSCoder documentation, you'll see 25 methods in the
>>> Swift version of the "Encoding General Data" section, and 27
>>> (non-deprecated) in the Objective-C version. `-encodeInt:forKey:` has no
>>> Swift equivalent. I'm not sure what the other missing method is.
>>> >
>>> > I think this is probably a bug or design oversight, and I'd recommend
>>> you file a radar against Foundation. If this is a primitive method for
>>> NSCoding, it needs to be accessible from Swift.
>>> >
>>> > --
>>> > Brent Royal-Gordon
>>> > Architechies
>>> >
>>>
>>>
>>
>>
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160721/1632d74d/attachment.html>