Re: swift and objective-c
Re: swift and objective-c
- Subject: Re: swift and objective-c
- From: Dietmar Planitzer <email@hidden>
- Date: Thu, 05 Jun 2014 22:51:55 -0700
- X_cmae_category: 0,0 Undefined,Undefined
On Jun 5, 2014, at 11:33 AM, Jens Alfke <email@hidden> wrote:
>
> On Jun 5, 2014, at 10:04 AM, Dietmar Planitzer <email@hidden> wrote:
>
>> let x = 4;
>> To me there is nothing in that statement that would make it clear that we are actually defining a constant here.
>
> IIRC, ‘let’ is pretty common in functional languages, for establishing immutable bindings. This goes all the way back to LISP (early ‘60s?) Swift has a lot of inspiration from functional languages.
Well the primary target audience for Swift is the existing ObjC/Cocoa developer community. It was in fact presented as a successor to ObjC. Consequently, it should preferably adopt syntax elements from that development realm instead of from functional languages. It is fine when functional programming languages use ‘let' to define a constant because those languages are part of their own separate framework of talking to a machine and have their own development history. But ObjC is not a functional programming language. Instead it grew out of the realm of imperative and OO languages and in that realm the keyword ‘let' has been used (again BASIC) to define variables rather than constants.
Somewhat ironically, the first definition that you get when you use Google to look up the definition of the verb ‘let’ is “not prevent or forbid; allow” which, well, is the exact opposite of what a constant is all about.
>> why not simply stick with the traditional ObjC and/or C/C++/Java style declaration syntax?
>> - (Int)foo:(Int)x {..}
>
> Really? I’ve always considered this the cruftiest part of Obj-C syntax, and something that always bewilders newbies.
For me the Swift function syntax feels crufty because of the way that it forces named parameters into a base syntax that does not extend well to named parameters and the end result is inconsistent syntax. In ObjC there is no difference between the first and the remaining name components of a method name:
foo:bar:zoo:
they are all created equal so to speak. But in Swift the first name component is special compared to the remaining name components because the first one is outside the parentheses and it may not actually itself take a parameter:
foo(foo:,bar:,zoo:)
To me the ObjC syntax looks more consistent and is consequently easier to read and to understand. It is certainly unusual compared to the typical function syntax of C, C++ & Co but I think the end result works well considering that the goal was to have a function syntax that allows explicit naming of parameters.
> It’s also extremely syntactically-ambiguous in a context where expressions could also appear, like a Swift REPL, which would seriously complicate the parser.
I do not care how hard it is for a machine to parse code as long as it is able to parse it correctly. I’m also first and foremost interested in a language that is designed such that the normal production flow of software works well. Everything beyond that is certainly welcomed when it is possible but it is also not as important.
>> Strings are passed by value. The reason that the language manual gives for that behavior is that it does this for safety reasons so that a string that we pass to a method can not be accidentally changed by it. However there are some bad consequences and surprising behavior that results from this design choice:
>
> This one does make me uneasy too. It does simplify the language not to have to have mutable/immutable class clusters, but it’s a big change from Obj-C, with which the language has to interact. (There’s also the weird discrepancy that strings and dictionaries are copy-on-write but arrays are pass-by-reference.)
Reading through the experience of other people with Arrays and Dictionary on the Apple dev forum, it looks like as if they indeed come with their own bags of surprising/unsafe behavior.
Anyway, when Swift was announced as a successor to ObjC and as a great language for Cocoa development I assumed that it would fully embrace the dynamic object model of ObjC and that its standard library would be Cocoa Foundation. My expectation was that String, Array and Dictionary would be just modernized names for NSString, NSArray and NSDictionary. My expectation was also that Swift’s built-in base class for objects would be NSObject. My assumption was that we could just write
import AppKit
class MyView : View {….}
because the compiler would map from the namespaced class names to the NS class names (by dropping the Swift namespace prefix and replacing it with the NS prefix or whatever else prefix the framework would specify in its module file). Finally, my assumption was that starting from this dynamic object model the Swift optimizer would lower Array & Co to C++ style std:vector or where possible flat arrays stored on the stack whenever possible and that it would lower method calls to vtable dispatched calls or straight function calls where possible.
But turns out that’s not how Swift works. It instead invents its own object model which AFAIK at this time is vtable based a-la C++. Instead it invents its own string, array and dictionary with very unusual and surprising behavior and limitations that shouldn’t be there to begin with. This also brings up the question whether features like operator overloading actually work with Cocoa classes. I.e. whether you’re able to define a + operator on NSString via an extension. I can’t currently test this but I suspect that this won’t work.
Regards,
Dietmar Planitzer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden