|
fleshweasel posted:Is it because declaring a variable of a strict type using "let" will prevent mutation of the "var" members of the struct anyway, thus making "let" properties on a struct pointlessly strict? Partially, but mainly because the semantics of value types make mutating a property and replacing the whole struct with a new one equivalent. You can even reassign self explicitly in a mutating function on a struct. For a reference type you might decide to have immutable properties to make sharing/concurrency less perilous, etc, but for a value type they should be very rare. Axiem posted:The thing is, this breaks encapsulation; now whoever wants to create a struct with one variable different has to know how that variable is stored internal to the struct. Not really, because you can replace a stored property with a computed property without having to change the call sites, just as you can change your internal storage while keeping the same initialisers in your example. Axiem posted:Doing it with the withX functions also gives me the ability to pause anywhere in the chain and capture the struct, do some more work and capture that, and possibly run comparisons on the two, especially around computed values. The Star example is admittedly a little weak in that arena, because they're effectively static in my game. If I understand this correctly, you can do that anyway. Make a copy of the struct, directly perform whatever mutations you like, then compare the two. Everything will work correctly even if you are mutating structs that are properties of other structs. Nothing about your withX functions is special in that regard.
|
#
?
Feb 27, 2016 19:57
|
|
|
|
| # ? May 15, 2024 01:24 |
|
|
jawbroken posted:If I understand this correctly, you can do that anyway. Make a copy of the struct, directly perform whatever mutations you like, then compare the two. Everything will work correctly even if you are mutating structs that are properties of other structs. Nothing about your withX functions is special in that regard. True; I just prefer to implicitly copy the struct rather than explicitly. I understand the point you're making, especially since as value types structs already do the copies as necessary. It's mostly that something bothers me about letting an external object manipulate an instance of the struct by directly modifying the properties, instead of going through a function interface. That and my default is to always write "let" unless there's a compelling reason to write "var", which is probably an overreaction to seeing people make things mutable way too often.
|
|
#
?
Feb 27, 2016 20:36
|
|
|
It's not at all ridiculous to have properties on a value type that don't expose setters. It might not make sense to independently modify that property, and you might want to push people towards some higher-level interface. For example, if you're going to store points using polar coordinates, it's not obvious that you should allow the Cartesian coordinate projections to be individually set; among other things, that's a really expensive operation compared to setting them both simultaneously. (My specific advice here is that this kind of representation difference is probably too central to pretend that you can reasonably abstract over it. An algorithm written to expect one representation is going to behave like poo poo given the other. You should probably just have two different point types and provide easy conversions back and forth.) Instinctively making everything immutable is definitely a sign of importing philosophy from other languages, though. The most important thing about code is your ability to understand what it's doing and why. Local mutable state doesn't create significant new challenges as long as you can still easily find everything that modifies or depends on a variable. (There are common objections to this argument like "but mutable variables can be modified by some arbitrary, obscure branch of the function!". The counter-argument is that that modification is happening for a reason: there is code that needs to use the modified value, not the original. Removing mutation doesn't eliminate that need, it just forces the value to be propagated manually out of that obscure branch and bound to a new name, achieving nothing other than making it harder to recognize the link between the old and new values.) Nor is it troublesome to pass a variable down to be mutated when it's obvious that that's what's happening. The problem with mutation comes when something can be modified outside of the immediate context, e.g. because it's global or otherwise shared state. But value types don't inherently present you with that problem, and so there's no reason to reflexively limit mutation in them.
|
|
#
?
Feb 29, 2016 05:59
|
|
|
rjmccall posted:Instinctively making everything immutable is definitely a sign of importing philosophy from other languages, though. On a similar note, are there any plans to have a 'strict' version of typealias? Or is it just a bad idea?
|
|
#
?
Mar 3, 2016 14:52
|
|
|
You mean something like Haskell newtype?
|
|
#
?
Mar 3, 2016 17:52
|
|
|
I don't really know Haskell at all but it looks like it, yeah...so having...code:
|
|
#
?
Mar 4, 2016 01:25
|
|
|
You can make an enum with one element pretty easily. The main (very large) usability gap of that vs. newtype is the ability to derive protocol conformances easily.
|
|
#
?
Mar 4, 2016 08:34
|
|
|
I just wanted to say kudos to the whole Swift team regarding swift-evolution and the development process. It's awesome watching the discussions and the progress of the entire project.
|
|
#
?
Mar 4, 2016 19:04
|
|
|
Anyone come across a good guide on getting parts of swift(oss) building locally? Seems like there is no consolidated getting started guide. Fresh clones off master and my build environment all pointing to lated Dev snapshots everything seems to be a weird mix of swift 2 and swift 3 style API that doesn't build. Nothing really mentioned If I had to build swift 3 off master and point my toolchain at that product before I could build XCTest or SwiftPM. Everything just mentioned using the Dev snapshots (I think since they are dated 3/1 they predate the swift3 api?) Posted to some mailing lists. So I'll see whats up eventually I hope.
|
|
#
?
Mar 13, 2016 18:54
|
|
|
Looks like I picked a poor weekend to try this. Foundation master was migrated to swift 3 api, but looks like the documentation/script to build the v3 toolchain is locked away in a PR. Once a snapshot is released there shouldn't be an issue I think.
|
|
#
?
Mar 13, 2016 20:46
|
|
|
Yeah, a lot of library things are a mess right now. Trust me, it's worse internally. No good way to do a massive library source break.
|
|
#
?
Mar 14, 2016 02:39
|
|
|
https://twitter.com/ashfurrow/status/715941778621206529
|
|
#
?
Apr 5, 2016 17:54
|
|
|
|
|
#
?
Apr 5, 2016 19:53
|
|
|
Yeah this owns.
|
|
#
?
Apr 5, 2016 20:29
|
|
|
I'm a somewhat new developer (bootcamp grad) and decided to start learning Swift recently. Uhm it's awesome. Coming from Ruby and JavaScript it feels really nice and very easy to learn. Gonna make that mobile money.
|
|
#
?
Apr 21, 2016 22:09
|
|
|
I only noticed today that the Swift Package Manager will generate you an Xcode project (as of a month and a half ago, I'm slow ok). You do that, flip your toolchain in Xcode preferences, and now you've got a real nice autocompleting environment for your Swift development needs. Definitely curious to see how Xcode 8 interacts with SPM. I'm tentatively excited to never use CocoaPods again.
|
|
#
?
Apr 28, 2016 00:35
|
|
|
pokeyman posted:I only noticed today that the Swift Package Manager will generate you an Xcode project (as of a month and a half ago, I'm slow ok). You do that, flip your toolchain in Xcode preferences, and now you've got a real nice autocompleting environment for your Swift development needs. Can you elaborate? My tired brain is reading this like it solves the choppy / slow / missing autocomplete, is that right?
|
|
#
?
Apr 28, 2016 02:04
|
|
|
Doesn't solve that directly (though I'm seeing much snappier autocomplete with the trunk toolset). What it solves for me is good editor support for making things using the Swift Package Manager. edit: previously it was just editing like a single file in Xcode outside of a project, you don't get any compiler-assisted autocomplete or inline errors.
|
|
#
?
Apr 28, 2016 02:44
|
|
|
So I just got this neat new job that I start in a couple of weeks. The company just recently (late last year-ish?) started doing everything Swift. That's great, but I don't know Swift at all. I tried watching those Stanford lectures but they were the most boring loving thing ever. I've been a full time iOS developer for a bunch of years, so I don't need to learn what Autolayout is or how to use a tableview. I just need to learn some Swifty stuff. What's the hot poo poo as far as books go? The OP is pretty empty.
|
|
#
?
Apr 29, 2016 02:19
|
|
|
status posted:So I just got this neat new job that I start in a couple of weeks. The company just recently (late last year-ish?) started doing everything Swift. That's great, but I don't know Swift at all. I tried watching those Stanford lectures but they were the most boring loving thing ever. I've been a full time iOS developer for a bunch of years, so I don't need to learn what Autolayout is or how to use a tableview. I just need to learn some Swifty stuff. What's the hot poo poo as far as books go? The OP is pretty empty. Have you looked at the books Apple provides on iBooks? https://itunes.apple.com/us/book/swift-programming-language/id881256329?mt=11 https://itunes.apple.com/us/book/using-swift-cocoa-objective/id888894773?mt=11 They're very informative. They aren't super jazzed up or anything though, I don't know how boring you might find them.
|
|
#
?
Apr 29, 2016 02:25
|
|
|
The Advanced Swift book from the-decreasingly-well-named objc.io sounds like it might be a good fit. Spends most of its time talking about things Swift does (well) that objc doesn't (do as well). It's up-to-date for Swift 2.2, which is nice because there's a lot of excited material out there talking about code that doesn't compile anymore. Then it spends the rest of its time talking about things that are trivially not a problem in objc. You can probably skip those parts if you're not interested.
|
|
#
?
Apr 29, 2016 02:34
|
|
|
Those three links are exactly what I need. Thanks!
|
|
#
?
Apr 29, 2016 02:54
|
|
|
Yeah the Swift guide from Apple is a hoot.
|
|
#
?
Apr 29, 2016 15:22
|
|
|
I'm just like forums poster 'status' above except I bought a big nerd ranch guide to swift. It's pretty good but I have a swift observation I'd like to make. Swift looks like it's a very versatile language and is extremely flexible and there exists opportunities to write really neat innovative code. However.... Would you agree the potential to write godawful loving spaghetti code is now also greater? Seems like a lot of the "benefits" of swift could easily be abused and make everything worse for everybody.
|
|
#
?
May 4, 2016 20:31
|
|
|
TheReverend posted:Would you agree the potential to write godawful loving spaghetti code is now also greater? Seems like a lot of the "benefits" of swift could easily be abused and make everything worse for everybody.
|
|
#
?
May 4, 2016 20:35
|
|
|
TheReverend posted:Would you agree the potential to write godawful loving spaghetti code is now also greater? Seems like a lot of the "benefits" of swift could easily be abused and make everything worse for everybody. What language features of Swift would you consider to enable spaghetti code?
|
|
#
?
May 4, 2016 20:40
|
|
|
Doctor w-rw-rw- posted:You haven't written much Objective C++ have you
|
|
#
?
May 4, 2016 20:48
|
|
|
I guess just the idea of a function, that takes another function as a parameter and returns multiple items,(one of which could be another function) blows my fragile little mind. Any one of these functions could have a nested function. I'm trying to keep an open mind. I'm sure I'll come around to it.
|
|
#
?
May 4, 2016 21:02
|
|
|
TheReverend posted:I guess just the idea of a function, that takes another function as a parameter and returns multiple items,(one of which could be another function) blows my fragile little mind. Any one of these functions could have a nested function. I just recently wrote an function to ramp a value, and it takes an 'interpolationFunction' argument. That way I can slip in whichever interpolation equation I want on the fly just by feeding it the function name. It's actually pretty cool - if I had to do it in Obj-C I'd probably need to make an enum entry for each function, then switch through an exhaustive list in the method body. Anyway it all comes down to what Spiderman's uncle said about power and responsibility, I guess.
|
|
#
?
May 4, 2016 21:15
|
|
|
TheReverend posted:Would you agree the potential to write godawful loving spaghetti code is now also greater? Seems like a lot of the "benefits" of swift could easily be abused and make everything worse for everybody. There are more ways that you can go out of your way to be perverse in Swift. I wouldn't say it's "easier", or at least not problematically so, because it's not like you're just throwing together a view controller and then, whoops, you accidentally slip up and define a bunch of confusing infix operators or structure all of your code into global getters. I think we've done a pretty good job of communicating how these things should be used — sparingly, and with solid justification — and so far I've been pretty satisfied with how the community has taken that to heart. I've never found the argument very convincing that languages should limit things like this just because they could be abused. Bored programmers will always find some way to act out; if anything, letting it be more clearly "abusive" makes it harder for them to actually justify checking it in when they're done, at least in contrast to standard bored-programmer practices like writing an amazing new ten-thousand-line framework to read configuration files. Edit: oh, I mean, higher-order programming can definitely be abused to make terrible spaghetti code, but in practice it's usually just "pass a function to another which will call it during its execution".
|
|
#
?
May 4, 2016 21:18
|
|
|
after working on an app where everything was based around dynamic dispatch by frankensteining selectors together with stringWithFormat, swift holds no nightmares for me
|
|
#
?
May 4, 2016 21:53
|
|
|
Swizzling methods is far worse than anything in swift.
|
|
#
?
May 4, 2016 22:56
|
|
|
I work exclusively in Notification-Oriented Programming.
|
|
#
?
May 5, 2016 01:53
|
|
|
All of my code is poo poo, regardless of the language.
|
|
#
?
May 5, 2016 19:46
|
|
|
Is it possible to demangle/C-ify certain symbol names in swift? In this case I want to make a Lua-autoloadable dylib. Lua transliterates module names to symbol names to search for.Objective-C code:code:For swift: code:code:
|
|
#
?
May 11, 2016 10:28
|
|
|
Swift uses, or will use, a different calling convention from C, so things like that are not reliable. That said, while we want to have a feature like "expose this as a C function", currently we don't, so that might still be your best bet. When we add the feature, you can move to it and your life will just get better. (The feature will, of course, promise that the exported symbol matches the C conventions for its type.)
|
|
#
?
May 11, 2016 16:17
|
|
|
I guess that would explain why 'force-loading' the raw symbol name randomly hard crashes (Xcode, not the actual process, heh) from one minute to the next (but works most times)? I'd been looking elsewhere. (Xcode seems mostly unharmed).code:
|
|
#
?
May 11, 2016 16:38
|
|
|
No, that actually doesn't seem like a likely culprit for that, actually. I have never seen that crash before.
|
|
#
?
May 11, 2016 16:40
|
|
|
Whatever it is, Xcode crashes very hard at the moment I attempt to package.loadlib using the raw symbol, tho not reliably. Somehow it doesn't kill the process itself, which does 'successfully' return a function in the lua interpreter (tho invoking that function will finally crash the app). If it doesn't kill Xcode, the received function is fine to call as well. Any timeline at all on the C interface? Along these lines I've been wondering, is swift really killing ObjC slowly? Swift seems to be able to utilize most/all of ObjC, but ObjC can only use a very limited subset of swift, and every day more swift libraries are made with seemingly nothing but more swift able to use them.
|
|
#
?
May 11, 2016 16:53
|
|
|
|
| # ? May 15, 2024 01:24 |
|
|
emoji posted:Along these lines I've been wondering, is swift really killing ObjC slowly? I sure hope so.
|
|
#
?
May 11, 2016 17:06
|
|
