|
rjmccall posted:The main limitation here for practical development is that we're not promising source compatibility in 1.0. Any idea on a timeframe for a 1.0 release for those of us who want to do practical development in Swift?
|
#
¿
Jun 2, 2014 22:19
|
|
|
|
| # ¿ Apr 29, 2024 05:47 |
|
|
Is Swift going to be supporting unit testing and the like? My workplace is thoroughly in the TDD camp (as am I), and having a language that really supports it would be fantastic. Also, is there any particular story you can tell on why a name that's going to be so impossible to google against was picked? Based on what I've read so far, the name is the thing I hate most about the language.
|
|
#
¿
Jun 3, 2014 04:44
|
|
|
Based on comments I've come across elsewhere on the Internet, it sounds like there are a lot of people with strong opinions about Swift, and they tend to be negative toward the language's design because of little things such as the range operators as noted above. You just can't win them all, I guess. (Frankly, I'm in the ".." includes the last number camp, mostly because I see that number as "standing in" for the last dot, but I can survive either way. It's something a good test should catch, if I get it wrong.) Tomorrow morning, when I can get back to Moscone (instead of dealing with lovely hotel Wi-Fi) I'm going to play around with the Unit Testing. Looking at the Swift documentation, I don't see any reference to private/public methods. Is everything public, or am I just missing something in the documentation?
|
|
#
¿
Jun 3, 2014 06:00
|
|
|
eschaton posted:XCTest has basic support for Swift, including the new testing features announced today. If there's anything specific you'd like to see in the Swift testing experience we'd love to hear your thoughts on it. I'll play with it and see what I come up with. Is the best way to provide feedback to file Radars, or is there someway else?
|
|
#
¿
Jun 3, 2014 16:30
|
|
|
So while trying to fiddle with Unit Testing, I've gotten to the point where I want to create mocks. I've imported the mocking framework that I want to use into the Xcode project as a subproject. I'm able to use it fine with Objective-C code in the project, and create mocks no problem. However, I can't get Swift to recognize that it's there (or, therefore, let me use the methods to mock something). What is the name of the module? I'm trying "import Stubble", and it says there is no such module. In Objective-C, I just need to "#import <Stubble/Stubble.h>", and it works. Or is there other voodoo I need to incant to make it work? (Or is this going to be answered in the Integrating Swift talk?) Edit: I do have a bridging header in my Test project now that has the "#import <Stubble/Stubble.h>" in it. That doesn't throw an error, but doesn't otherwise seem to do anything. Axiem fucked around with this message at 06:22 on Jun 4, 2014 |
|
#
¿
Jun 4, 2014 05:53
|
|
|
Doctor w-rw-rw- posted:They suggested filing a radar with a concrete suggestion such as the above. (Axiem, get on it) My colleague apparently got the same answer when he talked with the Apple technicians. Filing the radar is on my to-do list. An alternate solution would be, I suppose, for Apple to provide a mocking framework, but I don't think we'd see that until next WWDC at the earliest. Although, a couple of my colleagues and I have been talking about mocks and such, and it's possible that Swift is functional (technically speaking) enough that we can avoid dealing with mocks altogether, and focus more on the whole Functional Core, Imperative Shell thing. I'm going to have to fiddle with it some more to see what I can come up with. But I'll still file a radar for reflection/proxies, though if Apple either gives us a safe mocking framework or we can do TDD with FCIS, it's a bit more moot to me. Reflection allows for some crazy dangerous stuff, and I can see why Apple would want to avoid that. rjmccall, what do you make of this article on benchmarking Swift vs. Obj-C? Also, thanks, Hughlander, for putting the goonlunch together!
|
|
#
¿
Jun 5, 2014 07:41
|
|
|
Good talk, rjmmcall. Kinda sad that it ran over time, though, since I and my colleague were really interested in the Swift internals you were talking about. There should be a fourth talk for Advanced Advanced Swift  rjmccall posted:But the fact that the post started off by comparing unoptimized builds, and even now is comparing Swift (which uses ARC) against what seems to be manual refcounting, is not inspiring. I kind of figured as such. Their steadfast opposition to ARC because ~optimization~ doesn't ring well to my ears. Axiem fucked around with this message at 20:47 on Jun 5, 2014 |
|
#
¿
Jun 5, 2014 20:39
|
|
|
One thing I seem to recall hearing in one of the Swift talks this week is that objects in Swift don't have a root class (like objects in Obj-C have NSObject, or Java has Object, etc.). Is that actually the case? If so, why design the language that way?
|
|
#
¿
Jun 5, 2014 22:29
|
|
|
Flobbster posted:I've read through the section on two-phase initialization and I'm wondering, what is the reason for requiring that non-nullable ivars be initialized before super.init instead of merely by the end of the initializer body? This gets discussed in I believe the...Intermediate? Swift session (it's all a little blurry to me). Basically, though, when you call super.init(), there's a baked-in assertion in that super.init() that all properties that are not-optional have values (probably at the end of super.init(), if I had to guess, so that it can error out and prevent you from running with nil non-optionals. rjmmcall, I also meant to give you grief for hating on Ada in the Advanced Swift talk. Ada was the language my college used in CS 101, so I have a bit of a fondness for it. And really, with its extreme type safety, it works better than C in embedded systems, apparently.
|
|
#
¿
Jun 6, 2014 05:15
|
|
|
Oh, and I think I heard an Apple Engineer today slip up and use the code name for Swift instead of Swift. Those in Apple: any idea if it is actually a Firefly reference? (Or is it just as likely to have been the wrong word, but not the codename)
|
|
#
¿
Jun 6, 2014 05:36
|
|
|
Doh004 posted:I think he was trying to be nice by not revealing what her heard because, as rjmccall had mentioned earlier, they try to keep their non released names quiet? This. I would rather not incur the wrath of the Apple gods. Instead, I will note that in the Stump the Experts, one of the questions for the audience was "What was the code name for iCloud?", and after the audience gave the correct answer, one of the experts said (paraphrased) "When they first started the MobileMe replacement, the chosen code name was 'Mavericks', but we all thought it was a stupid name, so we decided to name it after a beer instead--thus, Newcastle"
|
|
#
¿
Jun 6, 2014 15:23
|
|
|
ManicJason posted:I was unreasonably excited to see that you can do pattern matching with ... and _ in the middle of case statements. It reminds me of the fun I had playing with Prolog in college. The insane power of the case statements in Swift is one of my favorite features of the language. It just gives you so much power compared to most languages.
|
|
#
¿
Jun 7, 2014 15:31
|
|
|
pokeyman posted:This doesn't really have much to do with Swift, though. We can take it to the Apple dev thread. On this note, my presumption is that sooner or later (probably when Xcode 6 is formally released), the Swift thread is going to be merged into the Apple dev thread, since a large portion of it is API calls, which are (effectively) the same between languages. Also, playgrounds are a fantastic way to show off the language to my co-workers, because I can just type some quick code and it shows it live updating. It's kind of nice to feel script-like, instead of having a heavyweight application around to do stuff in. I'm compiling my list of Radars to file. When I get a chance this weekend, I'll pull code together for them and do a dump. Sorry it's taking me so long.
|
|
#
¿
Jun 10, 2014 04:30
|
|
|
Ender.uNF posted:edit: Anyone have success creating a framework and using unit tests written in Swift? I haven't done anything special whatsoever and my first attempt to run a test fails: I've been able to get unit tests written in Swift (aside from the lack of mocking), so it's just stuff with the framework. In my opinion, though, the testing stuff for Swift isn't quite there yet--which makes sense with how much work is elsewhere in the language! On my list of radars to file this weekend is some stuff related to testing, so it'd probably be good to make your voice known there as well.
|
|
#
¿
Jun 12, 2014 02:57
|
|
|
This might be my lack of functional programming background speaking here, but what's the big deal with tail recursion? And why would I as a programmer even care whether or not the language is doing it--isn't it something under the hood anyway?
|
|
#
¿
Jun 22, 2014 06:41
|
|
|
Scaevolus posted:Some algorithms are naturally expressed as recursive functions. Writing recursive functions without a language promise that they'll be turned into tail calls (jump instead of call) is a quick way to overflow your stack. The only times I've caused a stack overflow when doing recursion is when I had a problem with the algorithm. I guess I just either haven't been using large enough data sets with it, or because I tend to shy away from recursion (because it is so easy to screw up on accident during code maintenance) I just haven't encountered a situation where it would cause a problem. If you're dealing with a situation where the recursion is complex enough that it causes a stack overflow, why not write it to use a loop instead?
|
|
#
¿
Jun 22, 2014 06:55
|
|
|
Holy poo poo, I somehow missed the point that optionals are enums under the hood 
|
|
#
¿
Jun 28, 2014 04:44
|
|
|
While fiddling around recently, I realized that Swift has built-in Array and Dictionary classes, but no corresponding Set class. Is there any particular reason for the omission? Are Sets just not used often enough to justify making a Swift counterpoint to NSSet? Or have I simply missed something in the docs? VVVVV So much for my memory. Hah. Good to know. Axiem fucked around with this message at 18:29 on Jul 2, 2014 |
|
#
¿
Jul 2, 2014 18:22
|
|
|
In the Objective-C project I am working on at my day-job, when the main Application Delegate starts up, it begins loading and indexing data before it bothers with loading any View Controllers, because that loading/indexing takes a while. This was starting to impact our Unit Tests with both performance and disk issues (as I understand it; I wasn't around before the following solution). To solve the problem, we have two application delegates; one of them is our main delegate, and the other is an application delegate for testing that loads a simple View Controller, and skips all of the hoolabaloo of our main application delegate. The way we accomplish this is that in our main.m file, we do the following: code:In my fun-things-at-night project, I'm playing around with Swift, and I'm wanting to do something similar, so that I'm not loading up the whole kit and kaboodle every time I run my tests. Is there a way to accomplish this sort of thing with Swift? There are two ideas that spring to mind: 1. Can I define an AppDelegate on a per-build-configuration basis? 2. If I must have one AppDelegate, is there a way that I can pass in a value from the build configuration to that AppDelegate, so that I can at least choose which View Controller to load?
|
|
#
¿
Jul 3, 2014 03:08
|
|
|
Plorkyeran posted:The simplest thing to do is just set an environment variable in the debug settings for your tests and check it with getenv. Huh. I did not know about that. Doing a little bit of looking, it appears that NSProcessInfo.processInfo().environment["TestBundleLocation"] is already set in the default testing schema, and not set in the actual running, so I can key off of that. So much for my effortpost
|
|
#
¿
Jul 3, 2014 05:14
|
|
|
Looks like a beta version of Xcode has dropped--and in this one, arrays are fixed! Still no access control, though 
|
|
#
¿
Jul 7, 2014 18:43
|
|
|
I am getting a weird problem, and I want to make sure I'm not crazy. Here is the relevant code. code:For reference, the function `whenSelectFromMap` takes as an argument ()->() and has no return, so its signature is more properly ( ()->() ) -> (), just to be confusing. Am I running into something weird with the trailing block syntax, or is this an actual bug?
|
|
#
¿
Jul 12, 2014 04:33
|
|
|
dizzywhip posted:Anyways, I'm fairly certain that the error is due to implicit returns of single-expression closures. Yep, that's the thing about closure syntax I completely forgot. Adding the return does indeed make it work as expected. I'll remember all of these things eventually!
|
|
#
¿
Jul 12, 2014 15:35
|
|
|
ufarn posted:Do we know for sure an update has been issued for the iBook? I too am struggling to follow the code examples where a bunch are now outdated, but I can't find any update to the iBook anywhere. I had to literally delete it and re-download it to get the updated text. Though only on OSX. On iOS, I haven't been able to get the new iBook for some reason. Axiem fucked around with this message at 20:02 on Jul 12, 2014 |
|
#
¿
Jul 12, 2014 19:57
|
|
|
I might have missed this somewhere along the way, but if I wanted to refer to a closure (/function) in the type of a generic declaration, what type do I use? In other words, I want to do: code:
|
|
#
¿
Jul 15, 2014 05:05
|
|
|
rjmccall posted:You could have the class be generic over two types, T and U, and then use the function type T->U within the declaration, though. I think this more or less answers my question, which is to say it's not possible. The context is that I'd like to build essentially a dictionary of Strings to Closures, to implement the...I think it's a Visitor pattern? Let's call this thing a VisitDictionary. A class (say, Alice) builds an instance of VisitDictionary<(Bob)->()>. Then Alice exposes a method whenCallSchoolRun((Bob)->()), which will take the (Bob)->() closure and add it to the VisitDictionary (the String being used for reference later in case it needs to be taken out of the dictionary). Later, an Alice will end up doing a callSchool, and then wants to tell the VisitDictionary "hey, all of those closures you have, run them please" as a way of notifying objects interested in when Alice "calls school". It would also be awesome if Alice could tell the VisitDictionary "and please use this Bob I have here", but I don't know how feasible that is sans serious reflection. Of course, that closure that a VisitDictionary is built with could be ()->() or (Bob, Carol)->(), or so on. But within the VisitDictionary, I wonder if it's possible to call that closure (hence the passing-in of Bob), instead of relying on Alice to call each closure. But that would clearly only be possible if I could constrain VisitDictionary<T> to only allow closures as T's. Right now I have this more or less written out, except the "run these closures" is a method that takes a closure that actually calls each closure. It might be that's the best I can do, though still expressing in the VisitDictionary that it only wants to store closures and not other things (like arrays) would be nice from a semantic perspective. ...this is probably a completely inverted way of describing the reasoning behind how this came about. Let me approach from the other direction. I mentioned off-handedly in the Apple dev thread that in Swift, I've been implementing an Observer pattern using closures. Alice will expose (I say despite the lack of private methods) a method whenCallSchoolRuns((Bob)->()). What I've been doing is just keeping those in an Array<(Bob)->()>, and when callSchool runs, I loop through that array and call each closure. That way, if a Deborah is interested in when an Alice calls the school, that Deborah can do: code:The problem with this is that once Deborah is observing an Alice, there's no easy way for Deborah to stop observing that Alice. Hence, the Token idea. Whenever you call whenCallSchoolRuns, it'll pass you back a token, so if you want to stop observing, you just call like noLongerWhenCallSchoolRuns(token) and given that token, it can eliminate the closure from the now-Dictionary (to map the token to the closure) But instead of repeating the boiler-plate code for generating the tokens (at the moment, a UUID, but it could be anything) or iterating through all of the values of the now-Dictionary, it would be nice to pull that out into a separate class that took care of some of that stuff (and was therefore testable as its own unit). Hence where I'm at. I'm able to make a VisitDictionary<T>, but still to actually call each of those closures, the Alice has to do something like this: code:For reference, the way the VisitDictionary is doing that at the moment (myDict is a Dictionary<String, T>): code:code:And it's late enough I'm probably also getting incoherent (and likely screwing up the differences between closures, functions, and methods). Hopefully that made sense. Axiem fucked around with this message at 05:55 on Jul 15, 2014 |
|
#
¿
Jul 15, 2014 05:53
|
|
|
I had a weird thing happen today. I have a part of my code that owns an enum that's used to keep track of its state. A couple of the states have associated values (because that's a really awesome feature of the enums), and I've set it up to conform to Equatable so that I can do some XCTAssertEquals on them. This evening, I added a new case to that enum, to represent a new state that I was creating. But when I went to do an XCTAssertEquals, I suddenly get an EXC_BAD_ACCESS at memory address 0x8 when I try to access Enum.NewCase. Switching it to any of the old cases works (in that it doesn't through the bad access exception). I poked at it for a while, and by adding a few more cases to the enum, I started getting the bad access exceptions (at various memory addresses that were all even and under 0x20) even on the cases that had been working. It tests, it was when trying to access Enum.NewCase. In the code, I could also get it to explode when just doing a switch on the variable that holds an enum. I could not, however, find any rhyme or reason as to when it would explode, except that it was consistent within a set (and particular ordering) of cases in the enum; when I changed that, it changed what broke where. I did, slightly earlier in the day, attempt to create a recursive enum, which it didn't like, and I've since completely killed DerivedData just in case something weird with that was hanging around. I'm kind of at my wit's end trying to figure out what I'm failing to implement. Could it be that I'm failing to account for the new case somewhere? Could it just be that the error is erroneous and something else is going wrong? Or could this be a real Swift bug for me to file? * Yes, yes, I know, there's supposedly a better way to do state machines in functional code. I don't know how to do it, and plan on learning sometime in the future. Right now I just want to get my code to work procedurally. Axiem fucked around with this message at 06:06 on Jul 17, 2014 |
|
#
¿
Jul 17, 2014 05:18
|
|
|
Sorry for the double-post, but it has been several days. Now, to change topics entirely. As I understand it, the @objc attribute makes something available to Objective-C in the same project. Is there a particular reason why protocols need to be @obj in order to define optional methods?
|
|
#
¿
Jul 19, 2014 03:23
|
|
|
rjmccall posted:@objc protocols are implemented via Objective-C message sends, so optional methods are easy to do with just conformsToProtocol/respondsToSelector checks. There's an obvious way to implement this for Swift native protocols, but we just haven't done it yet. That makes sense. It's just annoying because I have a protocol that I'd like to both have optional methods and also conform (be a sub-protocol of?) Equatable, and those appear to be mutually exclusive. I can survive, though, and just keep a bunch of empty methods around for now. Would it be worth filing a radar for optionals in non-@objc protocols, or is that the sort of thing y'all have on your board and don't need me to waste your time with?
|
|
#
¿
Jul 19, 2014 03:51
|
|
|
I have noticed that there is also a DebugPrintable protocol, though I haven't entirely figured out where it decides which protocol to use. And it doesn't appear to me as though say, XCTAssert* functions use either of them, either.
|
|
#
¿
Jul 20, 2014 22:50
|
|
|
Ender.uNF posted:rdar://17782662 filed to add the ability to export a module's internal members to another specified module. This makes unit tests on internal members much easier and allows two modules by the same developer to cooperate as if they were the same module, but without making that part of the public API. Yes, this is 100% the most annoying thing about access modifiers right now. Right after getting the beta 4 and fixing the fact that Double no longer auto-converts to CGFloat, I tried running tests and ended up with an awful lot of failures because I need to sprinkle "public" everywhere.
|
|
#
¿
Jul 23, 2014 23:55
|
|
|
dizzywhip posted:As an alternative to manually labeling everything as public, you can group your public API into an extension labeled as public, and everything inside that extension will default to public. In quite a few cases, this will end up being an extension of everything in the class. At the current state of the project, most of my things are either value objects or don't have much internal logic; they're all API.
|
|
#
¿
Jul 24, 2014 02:44
|
|
|
What protocol do I need to implement on an object so that XCTAssertEqual will output what I want in its default text, instead of the mangled name of the class? I've tried Streamable, Printable, and DebugPrintable to no avail. I'm getting really tired of my tests failing with the eternally unhelpful message `XCTAssertEqual failed: ("_TtC11SpaceTrains4Star") is not equal to ("_TtC11SpaceTrains4Star")`. It would be nice to be able to at least identify which is which in the output, so I could better figure out why a test is failing, and I'd rather not go and add my own custom format to each assertion when the default one is otherwise quite fine.
|
|
#
¿
Jul 29, 2014 00:14
|
|
|
Kallikrates posted:
Is there some reason you can't: code:Also, is there a reason you're insisting it be an NSObject, instead of just an object that conforms to Foo?
|
|
#
¿
Aug 3, 2014 13:47
|
|
|
Jeeze, Apple wasn't kidding when they talked about possibly changing the syntax. It's at the moment quite annoying to have to do this in every single one of my classes that inherits from UIView: code:I'm just curious if this is overzealousness at the moment, or how this whole "required" business is going to shake out.
|
|
#
¿
Aug 5, 2014 02:10
|
|
|
As I understand it, the sorts of things a language needs to be able to do in order to self-host don't have much in common with the sorts of things a language needs to do in order to be generally usable in developing GUI-having applications. It therefore becomes a matter of time and priorities: do you spend the time to self-host because...reasons; or do you spend the time building a language that people can use to create apps? For content: How is Swift/Obj-C interoperability for reals? I have someone on my team that wants to be aggressive about writing new stuff in Swift and converting over, but I'm not sold that it's going to be smooth sailing. Was wondering what sorts of real-life experience people have had.
|
|
#
¿
Feb 27, 2015 05:59
|
|
|
Nevermind, that's what I get for only looking at Swift documentation, and not double-checking against Objective-C methods that have been deprecated.
Axiem fucked around with this message at 21:29 on Mar 8, 2015 |
|
#
¿
Mar 8, 2015 20:41
|
|
|
So, serialization. I've got an object with a dictionary of structs. I'd like to serialize that dictionary of structs such that the next time I run the application, I can load it in and get the same thing. You know, basic serialization. Where I'm running into trouble is trying to figure out how to actually serialize those structs. I can make the class that owns the dictionary NSCoding-compliant, but I don't have any good way of serializing a dictionary of structs. If it were just one struct, I could encode the values necessary to re-create it--but to my knowledge, there's no easy way to do a set of structs en masse like that. At the moment, my solution is to turn my structs into classes and have them also conform to NSCoding, but that doesn't feel right to me, since they're supposed to be structs. But at the moment, I don't see any particularly good way of doing this. Trying to find anything on google doesn't get me very far, though a lot of people have figured out how to turn JSON into Swift structs/objects (which doesn't help me, as I'd need the inverse). Does my problem make sense? Have other people solved something like it? Is there a recommended approach? Is this something that might get addressed with a future version of Swift? Am I missing something obvious?
|
|
#
¿
Mar 19, 2015 05:38
|
|
|
With fiddling with NSJSONSerialization, I've been able to do some custom stuff around serializing structs, which makes sense. Thanks, thread! But now I'm beset by a bit more of a design-pattern-theory question. In the general case, what is preferred: that an object knows how to serialize/deserialize itself, or that another object (/function) knows how to do it, and why? To a certain extent, I can see arguments for both sides, and I know the Foundation way is for objects to do it themselves, but I don't know why that's the case, or if another method is now preferred in language design. I kind of figure that now that Swift is all new and shiny, we should consider going with the preferred paradigm instead of slavishly following Foundation just because.
|
|
#
¿
Mar 21, 2015 04:06
|
|
|
|
| # ¿ Apr 29, 2024 05:47 |
|
|
I'm using SwiftyJSON for parsing my JSON into objects, and I haven't had any problems with it. Certainly, I'd much rather something standard from Apple, but I like this much more than futzing with NSJSONSerialization and NSObjects. On another note, today I spent a good hour trying to figure out some of my serializing-into-JSON stuff before I discovered that you can't cast an array of Swift objects into an array of Swift protocols. Namely, if class Foo conforms to protocol Bar, if you have x: [Foo] and y: [Bar], trying to assign x into y will cause a crash with the very unhelpful message that the array can't be bridged from Objective-C. Apparently you can do some voodoo to make it work if you sprinkle @objc around in places, but I am trying very hard to be pure Swift, and not be beholden to any Objective-C things like that. I'm probably crazy  Honestly, though, while I love Swift, I have a guy at my workplace that wants to start having us write new classes in Swift, and I'm just not quite there yet. Personal project with no timeline, sure. Major piece of software for major client? I'm just a little wary. ...but I really do look forward to seeing what cool new stuff gets revealed at WWDC. I imagine (hope) there'll be a major version release then. Though still, at the top of my wishlist is for Refactor -> Rename to work in Xcode.
|
|
#
¿
Mar 22, 2015 05:23
|
|