Re: Bindings in Swift

[Quincey Morris]

On Aug 11, 2014, at 16:14 , Greg Parker  wrote:

> Do you have an example?

For example (beta 5), enter some source that uses type “Array”, then 
command-click on “Array”. (I don’t know how to get Xcode to display the 
resulting file directly, so I’ve been using this technique. I don’t know if the 
result is real or synthetic.)

Look for the 2nd “extension Array”, and the 2nd constructor in this extension:

init(_ s: S)

or look at ‘extend’ or look at ‘join’.

Incidentally, I had other issues when trying to use things declared in this 
file. For example, if I try to define a class that conforms to “Collection”, 
the compiler says “‘Collection' is ambiguous for type lookup in this context”.

(What I was trying to do was define a new class that had the same interface as 
an Array, but had only the immutable parts of the interface as its public API.)

___

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

Re: Bindings in Swift

[Roland King]

> On 12 Aug 2014, at 7:14 am, Greg Parker  wrote:
> 
> On Aug 10, 2014, at 3:00 PM, Quincey Morris 
>  wrote:
>> There’s also something going on with the silly-looking generic specifier 
>> ‘’ that appears in some of Swift’s internal class 
>> declarations, but it seems to be meaningful in relation to protocols in some 
>> non-obvious way.]
> 
> Do you have an example? I don't think the standard library actually uses that 
> construct. Perhaps there's a bug in the interface display generator where it 
> gets confused by some other constraint declaration.
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 

There was one - it was mentioned here 
https://devforums.apple.com/message/993199#993199 
 - don’t know if it still 
exists or not, don’t remember seeing one for a while but I haven’t been very 
Swifty recently. 
___

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

Re: Bindings in Swift

[Greg Parker]

On Aug 10, 2014, at 3:00 PM, Quincey Morris 
 wrote:
> There’s also something going on with the silly-looking generic specifier ‘ T where T == T>’ that appears in some of Swift’s internal class declarations, 
> but it seems to be meaningful in relation to protocols in some non-obvious 
> way.]

Do you have an example? I don't think the standard library actually uses that 
construct. Perhaps there's a bug in the interface display generator where it 
gets confused by some other constraint declaration.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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

Re: Bindings in Swift

[Quincey Morris]

On Aug 10, 2014, at 14:39 , Roland King  wrote:

> I haven't yet understood why there are two different syntaxes for 
> class/function generics, with the  syntax but protocols are unadorned 
> but have associated types. Naively I would have expected both to look the 
> same, with parameters in angle brackets

Well, the semantics *are* different. Each “parameterized” class is a different 
type, but all “parameterized” protocols (of the same name, I mean) are the same 
type. A while back I did start to consider what a "generic protocol” might 
mean, instead of a type-associated one, but my head immediately started to hurt.

> I think it's time to resurrect the Swift book and read the second 1/2 of it 
> more slowly than I did the first time.

I wouldn’t hold out much hope. The book just skates over the surface. In 
particular, it seems to me that what it says about associated types in 
protocols is either pure nonsense, or is missing a couple of key facts.

[Specifically, I suspect that a ‘typealias’ in a protocol must either get bound 
to a specific auxiliary type in an inheritor of the protocol, otherwise it 
defaults to being bound to the inheritor’s type (i.e. ‘Self’). However, it 
looks to me that the specific binding is generally by inference, and so is 
indistinguishable syntactically from the default binding. The book describes 
one thing, but links to an example that shows the other.

There’s also something going on with the silly-looking generic specifier ‘’ that appears in some of Swift’s internal class declarations, but 
it seems to be meaningful in relation to protocols in some non-obvious way.]

___

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

Re: Bindings in Swift

[Roland King]

>> Deliberately missing your point, I’d say the problem is that Swift has two 
>> kinds of generics — one for class types and one for protocols. The concepts 
>> are fairly easy to grasp individually, but become horrendously complex when 
>> allowed to interact. Personally, I regard this as a bug in the language 
>> design.
>> 
>> OTOH, C++ has historically proved that generics (i.e. templates)
> 
> I really wish people would stop referring to C++ templates as generics. C++ 
> template arguments can be numbers, strings, types, or anything else, and the 
> compiler will sit there and dutifully compute whatever program you encode via 
> templates.
> 
> Generics are strictly type parameterization. They are far simpler to 
> understand and implement. And Swift has some techniques to avoid some of the 
> problems that arise even in “normal” use of C++ templates, like associated 
> types (to keep generic type signatures simple) and a type inference algorithm 
> that doesn’t completely suck.
> 

I haven't yet understood why there are two different syntaxes for 
class/function generics, with the  syntax but protocols are unadorned 
but have associated types. Naively I would have expected both to look the same, 
with parameters in angle brackets, clearly there's a very good reason for it, I 
just don't have the kind of experience with doing it another way, ie very much 
experience with C++ templates and their entire drawer of sharp edges, to 
appreciate it. 

I think it's time to resurrect the Swift book and read the second 1/2 of it 
more slowly than I did the first time. 


___

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

Re: Bindings in Swift

[Quincey Morris]

On Aug 10, 2014, at 10:15 , Kyle Sluder  wrote:

>> OTOH, C++ has historically proved that generics (i.e. templates)
> 
> I really wish people would stop referring to C++ templates as generics.

Point taken, dope-slap administered.

___

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

Re: Bindings in Swift

[Charles Srstka]

On Aug 9, 2014, at 8:44 PM, Quincey Morris 
 wrote:

> On Aug 9, 2014, at 18:13 , Roland King  wrote:
> 
>> If this is where we are then it would be handy to have the runtime throw, or 
>> at least log, if you attempt to KVO a Swift property which isn't dynamic.
> 
> Yes, though I expect (hope?) that there is eventually something better than 
> traditional KVO/bindings/etc coming along for Swift. (Note, for example, that 
> did/willSet takes over a little bit of the KVO universe. Just not very much.)

What would be nice to see in a KVO replacement would be some kind of markup, 
like an "observable" keyword, to let callers know that a given property is 
observable. With the current system, there's no way to know whether the 
property is dynamically based on some other property and whether the class is 
internally implementing the +keyPathsForValuesAffectingFoo methods to make the 
property work properly with KVO other than hoping that it's mentioned in the 
documentation.

Charles

___

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

Re: Bindings in Swift

[Kyle Sluder]

On Aug 10, 2014, at 9:56 AM, Quincey Morris 
 wrote:
> 
>> On Aug 10, 2014, at 06:46 , Roland King  wrote:
>> 
>> And if anyone thinks Swift is all simplicity and scripty loveliness I came 
>> across this StackOverflow question and answer today. It will be a while 
>> before I entirely understand it, it will be a long while before I could 
>> attempt to reproduce it.
> 
> Deliberately missing your point, I’d say the problem is that Swift has two 
> kinds of generics — one for class types and one for protocols. The concepts 
> are fairly easy to grasp individually, but become horrendously complex when 
> allowed to interact. Personally, I regard this as a bug in the language 
> design.
> 
> OTOH, C++ has historically proved that generics (i.e. templates)

I really wish people would stop referring to C++ templates as generics. C++ 
template arguments can be numbers, strings, types, or anything else, and the 
compiler will sit there and dutifully compute whatever program you encode via 
templates.

Generics are strictly type parameterization. They are far simpler to understand 
and implement. And Swift has some techniques to avoid some of the problems that 
arise even in “normal” use of C++ templates, like associated types (to keep 
generic type signatures simple) and a type inference algorithm that doesn’t 
completely suck.

--Kyle Sluder
___

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

Re: Bindings in Swift

[Quincey Morris]

On Aug 10, 2014, at 06:46 , Roland King  wrote:

> And if anyone thinks Swift is all simplicity and scripty loveliness I came 
> across this StackOverflow question and answer today. It will be a while 
> before I entirely understand it, it will be a long while before I could 
> attempt to reproduce it. 

Deliberately missing your point, I’d say the problem is that Swift has two 
kinds of generics — one for class types and one for protocols. The concepts are 
fairly easy to grasp individually, but become horrendously complex when allowed 
to interact. Personally, I regard this as a bug in the language design.

OTOH, C++ has historically proved that generics (i.e. templates) *alone* can 
become horrendously complex. Even on this list, the most common C++ question 
is, “Why won’t my template instantiate properly?”.

One of the joys of Obj-C has always been that it isn’t very ambitious in the 
language-features department. Remember the fuss when property syntax was 
introduced?


___

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

Re: Bindings in Swift

[Roland King]

> 
>> if you write such a property in Swift and mark it only @objc then it's quite 
>> possible Swift will call the original, unswizzled methods, and you won't get 
>> your notification .. because objc_MsgSend may not be used
> 
> Yes, I suppose if Swift decided to use a direct call, it would call the wrong 
> thing, but not because of swizzling, since KVO doesn’t swizzle. Instead, it 
> dynamically changes the class of your object to a synthetic class with a 
> method that overrides your setter. So, the error in Swift’s “reasoning” would 
> be that the method wasn’t overridden when it really was.
> 

Some nice person pointed me to the documentation which says in black and white 
(and blue and a bit of purple and green) that you need dynamic for KVO-able 
Swift properties. And I believe my thought process finally got to the bottom of 
the well and I understand what the differences are between dynamic, @objc and 
not having anything at all. 

https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/AdoptingCocoaDesignPatterns.html#//apple_ref/doc/uid/TP40014216-CH7-XID_9

I still suck at Swift and when I need to knock something up to test in 10 
minutes find myself reaching for the trusty ObjC toolbelt. I suspect I need 2 
projects to get anywhere, the first one to do it all badly wrong and write 
Swift which is just wrapped ObjC and the second one to actually start thinking 
in the language. 

And if anyone thinks Swift is all simplicity and scripty loveliness I came 
across this StackOverflow question and answer today. It will be a while before 
I entirely understand it, it will be a long while before I could attempt to 
reproduce it. 

http://stackoverflow.com/questions/24070873/error-using-associated-types-and-generics/24845414#24845414
___

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

Re: Bindings in Swift

[Quincey Morris]

On Aug 9, 2014, at 18:13 , Roland King  wrote:

> If this is where we are then it would be handy to have the runtime throw, or 
> at least log, if you attempt to KVO a Swift property which isn't dynamic.

Yes, though I expect (hope?) that there is eventually something better than 
traditional KVO/bindings/etc coming along for Swift. (Note, for example, that 
did/willSet takes over a little bit of the KVO universe. Just not very much.)

> If I have understood properly, up until beta 4 that also used objc_MsgSend 
> and was fully dynamic, as of beta 5 it may or may not use objc_MsgSend or it 
> may optimize around it.

I got the impression that earlier betas might have optimized around it, and 
therefore that KVO wasn’t reliable. I think ‘dynamic’ is a bug fix.

> if you write such a property in Swift and mark it only @objc then it's quite 
> possible Swift will call the original, unswizzled methods, and you won't get 
> your notification .. because objc_MsgSend may not be used

Yes, I suppose if Swift decided to use a direct call, it would call the wrong 
thing, but not because of swizzling, since KVO doesn’t swizzle. Instead, it 
dynamically changes the class of your object to a synthetic class with a method 
that overrides your setter. So, the error in Swift’s “reasoning” would be that 
the method wasn’t overridden when it really was.




___

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

Re: Bindings in Swift

[Roland King]

> On 10 Aug 2014, at 4:35 am, Quincey Morris 
>  wrote:
> 
> 1. Don’t forget to mark your observable methods and properties as ‘dynamic’ 
> (new in the latest beta).
> 
> Now that I think about it, though, I hate this “enhancement”. It turns 
> something that’s relatively simple to use (bindings or KVO) into something 
> that’s obscure for Cocoa newbies, and gives us one more housekeeping task to 
> forget, even if we’re newbies.
> 

I've been trying to understand the implications of dynamic and @objc to work 
out if we do now have to mark properties written in Swift, usable from 
objective-C, as dynamic in order for them to be KVO-able. I think you're right 
here and you do. 

I'm assuming that Swift calling an ObjC method written in ObjC has to use 
obj_msgSend because that's all the ObjC code knows. When ObjC calls a method in 
Swift (which must be marked @objc implicitly or explicitly) it uses 
objc_msgSend because that's all it knows, and the Swift method supports that. 

That leaves Swift calling a Swift method which is also marked @objc. If I have 
understood properly, up until beta 4 that also used objc_MsgSend and was fully 
dynamic, as of beta 5 it may or may not use objc_MsgSend or it may optimize 
around it. Only if you mark a Swift method as 'dynamic' is it guaranteed to 
always be dynamic (which currently also means use objc_MsgSend as that's the 
only dynamic runtime there is at this point). 

If that's all correct then it seems that, as observing a property swizzles the 
class methods so that sets to the value cause a KVO notification to go out, if 
you write such a property in Swift and mark it only @objc then it's quite 
possible Swift will call the original, unswizzled methods, and you won't get 
your notification .. because objc_MsgSend may not be used. 

I understand the desire to reduce fully dynamic dispatch as much as possible, 
thats's good. KVO was always a little bit magical, you had to use a 
KVO-compliant way of mutating the property (how many messages have we seen 
about that over the years) and you never knew if any given property of someone 
else's class was or was not mutated in a KVO compliant way, however KVO was 
quite deeply baked in to the runtime and kind of just worked and now it looks 
like it's going to not quite just work. Perhaps only old-timers use KVO :)

Now it looks more like you have to know if you want a property to be KVO 
observable you need to make it dynamic. I guess on the flipside, if a property 
is marked dynamic you could sure that it's KVO compliant because the after KVO 
has swizzled the setter, there's no other way to set the property but than to 
call it, so that might be good. 

If this is where we are then it would be handy to have the runtime throw, or at 
least log, if you attempt to KVO a Swift property which isn't dynamic. 



___

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

Re: Bindings in Swift

[Quincey Morris]

On Aug 9, 2014, at 09:48 , Gerriet M. Denkmann  wrote:

> Are bindings supposed to work in Swift?

I haven’t played with them at all, yet, but they have to work (eventually, even 
if not yet), or interoperability couldn’t work. But …

1. Don’t forget to mark your observable methods and properties as ‘dynamic’ 
(new in the latest beta).

Now that I think about it, though, I hate this “enhancement”. It turns 
something that’s relatively simple to use (bindings or KVO) into something 
that’s obscure for Cocoa newbies, and gives us one more housekeeping task to 
forget, even if we’re newbies.

2. Is your class a subclass of NSObject? If not, or maybe even if so, you have 
name-mangling and namespace (i.e. module name) issues to be wary of.

3. You could try getting Xcode to generate the Obj-C bridging header and see 
what it says about your class from an Obj-C perspective.
___

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