Swift Thinking [video]
realm.io
Swift Thinking [video]
1–10 of 14 posts
Re: Swift Thinking [video]
#2Most these operator discussions seem to go down the same way: "man you can make some really confusing operators, and I hope that doesn't become a thing... but gee writing == is so much nicer than isequalto and can't beat the + operator when adding things together!". People seem convinced that its all or nothing. Lua has such a nice compromise to this: you can overload +, -, ==, etc using special methods (__add, etc.), and you can't overload or create any new operators. Its a completely controlled environment that disarms the "but what if I want to add complex numbers together!" argument while still removing the temptation to create really absurd syntax (which Swift has taken to the next level with emoji).
Re: Swift Thinking [video]
#3Most these operator discussions seem to go down the same way: "man you can make some really confusing operators, and I hope that doesn't become a thing... but gee writing == is so much nicer than isequalto and can't beat the + operator when adding things together!". People seem convinced that its all or nothing. Lua has such a nice compromise to this: you can overload +, -, ==, etc using special methods (__add, etc.)…
The Objective-C community also has a language that allows all sorts of weirdness and also (perhaps in part because of that freedom) has a uniquely pervasive emphasis on convention. Wacky stuff is tolerated and even appreciated in the appropriate contexts but generally shunned and avoided otherwise. It seems likely that the Swift community (overlapping in such large part with the Objective-C community) will inherit this.
Re: Swift Thinking [video]
#4Most these operator discussions seem to go down the same way: "man you can make some really confusing operators, and I hope that doesn't become a thing... but gee writing == is so much nicer than isequalto and can't beat the + operator when adding things together!". People seem convinced that its all or nothing. Lua has such a nice compromise to this: you can overload +, -, ==, etc using special methods (__add, etc.)…
The Objective-C community also has a language that allows all sorts of weirdness and also (perhaps in part because of that freedom) has a uniquely pervasive emphasis on convention. Wacky stuff is tolerated and even appreciated in the appropriate contexts but generally shunned and avoided otherwise. It seems likely that the Swift community (overlapping in such large part with the Objective-C community) will inherit th…
What are you thinking about specifically?
Re: Swift Thinking [video]
#5Earlier quoted context omitted.
The Objective-C community also has a language that allows all sorts of weirdness and also (perhaps in part because of that freedom) has a uniquely pervasive emphasis on convention. Wacky stuff is tolerated and even appreciated in the appropriate contexts but generally shunned and avoided otherwise. It seems likely that the Swift community (overlapping in such large part with the Objective-C community) will inherit th…
What are you thinking about specifically?
With regard to Objective-C's ability for weirdness? Its dynamic nature could easily lead to really weird/surprising process flow. It seems like lots of developing Obj-C programmers know about method swizzling but I wouldn't necessarily expect a similarly-experienced C++ programmer to be familiar with such things in practice.
On the conventionality side: Cocoa is known for its consistency in naming and behavior.
Re: Swift Thinking [video]
#6If you watch the video and wondering about the multiple subscripts prepended by '?', this technique is called optional chaining. It also work for properties and methods.
It is kinda similar to how we can invoke methods on 'nil' in Objective-C and not causing any runtime error.
Just stating if anyone is wondering.
Re: Swift Thinking [video]
#7Most these operator discussions seem to go down the same way: "man you can make some really confusing operators, and I hope that doesn't become a thing... but gee writing == is so much nicer than isequalto and can't beat the + operator when adding things together!". People seem convinced that its all or nothing. Lua has such a nice compromise to this: you can overload +, -, ==, etc using special methods (__add, etc.)…
Well, C++ has the same restriction and a lot of people's distaste of overloaded operators comes from that language. User-defined operators and overloaded operators are separate features, in fact—OCaml has the former but not the latter.
My personal preference is to allow operator overloading, but to (a) enforce that overloaded operators must have reasonable type signatures (via concepts or similar); (b) restrict overloadable operators to mathematical operators (e.g. not the comma operator), and (c) set a good precedent in the standard libraries and community against using mathematical operators for non-mathematical operations (e.g. don't overload bitshift operators for I/O in the standard libraries).
Re: Swift Thinking [video]
#8Earlier quoted context omitted.
What are you thinking about specifically?
With regard to Objective-C's ability for weirdness? Its dynamic nature could easily lead to really weird/surprising process flow. It seems like lots of developing Obj-C programmers know about method swizzling but I wouldn't necessarily expect a similarly-experienced C++ programmer to be familiar with such things in practice. On the conventionality side: Cocoa is known for its consistency in naming and behavior.
Swizzling is a weird one in the community. But if I see #import something has gone wrong (you have to include that for swizzling and other seemingly dangerous stuff)
Re: Swift Thinking [video]
#9Most these operator discussions seem to go down the same way: "man you can make some really confusing operators, and I hope that doesn't become a thing... but gee writing == is so much nicer than isequalto and can't beat the + operator when adding things together!". People seem convinced that its all or nothing. Lua has such a nice compromise to this: you can overload +, -, ==, etc using special methods (__add, etc.)…
I for one can't wait to create circular references between objects that then stay alive together for ever and ever using the ❤❤❤ operator.
More seriously, I wonder why user-defined operators are considered any worse than user-defined functions. I mean, I think that they often are, but I wonder why.
Maybe we assume less potential for ambiguity when we read a symbol than when we read a word. The possibility that isEqual: has a bad implementation that doesn't respect transitivity seems more obvious than the possibility that == does.
Re: Swift Thinking [video]
#10Earlier quoted context omitted.
With regard to Objective-C's ability for weirdness? Its dynamic nature could easily lead to really weird/surprising process flow. It seems like lots of developing Obj-C programmers know about method swizzling but I wouldn't necessarily expect a similarly-experienced C++ programmer to be familiar with such things in practice. On the conventionality side: Cocoa is known for its consistency in naming and behavior.
Swizzling is a weird one in the community. But if I see #import something has gone wrong (you have to include that for swizzling and other seemingly dangerous stuff)
I think it's perfectly fine for meta-level code.
Such meta-level code should be encapsulated well and be very useful.