|
Honestly, these days, I'd much rather we never see optional methods in protocols. Now that we can pass around closures as first-class objects in variables, I can't actually think of a use case where I'd want to conform to a protocol but not have to implement all the protocol's methods.
|
# ? May 15, 2015 21:56 |
|
|
# ? May 28, 2024 14:36 |
|
Kallikrates posted:How are you guys handling the optional protocol pattern in swift? I want to make it a rule that if you need this pattern in swift to not use @objc, but to use inheritance or composition of different protocols and optionals. But I'm getting push back because of what I think is a crufty reason. Strictly speaking? Multiple protocols, possibly inheriting from each other if necessary. Bigger picture? Apple's delegate pattern (and use of protocols in general) conflate different concerns: a potentially unbounded stream of async event notifications and querying for values when they are needed. I have the option to ignore valueChanged. I cannot ignore tableView:cellForRowAtIndexPath: and still have a useful table view. I'm starting to lean toward stuff like ReactiveCocoa 3.0 (Signal/SignalProducer) because honestly, why try to cram an Objective-C pattern into a wholly new language?
|
# ? May 15, 2015 23:31 |
|
cellForRow is a data source method, not a delegate one. People super-abuse the delegate pattern for communication (it should be for extension of functionality, bagawd) but it has a good place in the list of techniques.
|
# ? May 16, 2015 00:27 |
|
Forgive my ignorance, but what does putting "import Foundation" or "import UIKit" at the top of a given Swift file inside a project actually do? I understand that in say, C, you provide header files in #import statements in order to let the linker do its job, but that was at a per-file level, not a per-module level. Following up on that, is there any compelling reason not to be able to say "just consider every file in this project to `import Foundation`"? It just seems odd to me that for Foundation, UIKit, or even any module that touches much of my code, I have to clearly define that I'm importing it. I guess what I'm saying is, is there a compelling reason not to have a Swift version of Prefix.pch to do this for us?
|
# ? May 20, 2015 03:54 |
|
Axiem posted:Forgive my ignorance, but what does putting "import Foundation" or "import UIKit" at the top of a given Swift file inside a project actually do? I understand that in say, C, you provide header files in #import statements in order to let the linker do its job, but that was at a per-file level, not a per-module level. Header files in C-family languages aren't for the linker, they're for the compiler: In order to use functions or variables the compiler needs to see declarations for them, so it knows how to generate code to access them. This is done via direct text inclusion, which has its pluses and minuses. And it's the generated code (along with a list of libraries to look in for external definitions) that gets fed to the linker, not the headers. With Swift you can effectively treat module imports as the same sort of thing, just fancier. The compiler is basically doing the equivalent of precompiled prefix headers for you behind the scenes, because it doesn't have to worry about the language semantics specifying that literal text inclusion happens. (This also applies to @import in Objective-C.) quote:Following up on that, is there any compelling reason not to be able to say "just consider every file in this project to `import Foundation`"? It just seems odd to me that for Foundation, UIKit, or even any module that touches much of my code, I have to clearly define that I'm importing it. It helps the modularity of your code to be explicit about what it's using. As an example, if a class doesn't truly depend on anything from UIKit, it shouldn't import UIKit, and that means it'll be portable to OS X too. As an example, a couple years back I experimentally extracted an Awful.framework from Awful.app that would work on OS X. 99% of it didn't need UIKit and came right over, so it should have all just imported Foundation. (The only thing that didn't was something that triggered the network activity indicator, which was easily just abstracted behind a delegate.) In general, you'll find that lots of oldschool NeXT developers treat development as an exercise in putting together a bunch of frameworks that then get composed into one or more apps. Part of doing this is clearly defining the boundaries between the different parts of your app, which includes considering their dependencies.
|
# ? May 20, 2015 07:24 |
|
eschaton posted:Part of doing this is clearly defining the boundaries between the different parts of your app, which includes considering their dependencies. This is so very much gold packed into such a simple sentence.
|
# ? May 20, 2015 07:52 |
|
eschaton posted:In general, you'll find that lots of oldschool NeXT developers treat development as an exercise in putting together a bunch of frameworks that then get composed into one or more apps. Part of doing this is clearly defining the boundaries between the different parts of your app, which includes considering their dependencies. I come from the C++ tree of OOP semantics, and have been wondering why the internal access control works as it does, and not like protected. Is this the answer to the question I didn't ask?
|
# ? May 20, 2015 13:50 |
|
eschaton posted:Part of doing this is clearly defining the boundaries between the different parts of your app, which includes considering their dependencies. This does make sense to me, and is something I miss about the header-file-inclusion-tree from C (but not enough to want it back). It does make sense to me not to make all these non-UI things use UIKit (although, if they need CGFloats...). But Foundation? A logging framework (like CocoaLumberjack) that's used everywhere? Honestly, Foundation and XCTest are the two that I'm just getting tired of typing in all of my files (all my test files, in the latter case, at least). And also in my test files telling them all to import my main module (because why would I not want to do this?). Many of the rest of the modules, like UIKit, I'm totally cool with not allowing this for the reasons you mentioned.
|
# ? May 20, 2015 16:47 |
|
dupersaurus posted:I come from the C++ tree of OOP semantics, and have been wondering why the internal access control works as it does, and not like protected. Is this the answer to the question I didn't ask? internal works like it does because that's how internal works in every language that has the concept (e.g. C#) The reason why it's in Swift but protected isn't is probably related to that, though. Here's the Swift blog post on the reasoning for not having protected.
|
# ? May 20, 2015 23:42 |
|
Is there a possibility of being able to assign from switch statements? I'm writing a Chip-8 interpreter in Swift, decoding instructions using tuples in a switch statement, but each operator needs to return a value. Right now I set a 'result' value in every case statement, but it would be nice if I could do this...code:
|
# ? May 24, 2015 15:03 |
|
code:
|
# ? May 24, 2015 15:44 |
|
Oh, well thats quite nice isn't it! Thanks! Edit to add: that works but you have to be explicit about the return type, type inference doesn't seem to be able to figure it out. I've got another question, would it be possible to have a 'strict' version of typealias that means that the alias is treated as it's own distinct type, rather than just an alias? So something like this would create a compiler error: code:
toiletbrush fucked around with this message at 17:09 on May 26, 2015 |
# ? May 24, 2015 20:13 |
|
What's the intended use differentiation between tuples and structs? I know that on the extremes, if you have a single function with multiple returns use a tuple, and if you need methods and such use structs. But what about that grey area where the same two bits of information appear in many places -- call it (balls:Int, strikes:Int) -- so writing that tuple signature everywhere gets tedious, but everything that uses the data is external so there's no need for any methods. Do I typealias the tuple, make a struct, or does it not really matter?
|
# ? May 27, 2015 03:01 |
|
Typealiasing a tuple is probably not ever a sensible thing to do. Outside of generic programming scenarios where you can't use a struct with meaningful names, the main reason to use a tuple is where a struct would be pointless boilerplate. If you're using a specific type of tuple enough places to justify a type name, then defining a struct instead is not massively boilerplate-inducing. There's definitely nothing wrong with a struct with zero methods.
|
# ? May 27, 2015 03:29 |
|
dupersaurus posted:What's the intended use differentiation between tuples and structs? I know that on the extremes, if you have a single function with multiple returns use a tuple, and if you need methods and such use structs. But what about that grey area where the same two bits of information appear in many places -- call it (balls:Int, strikes:Int) -- so writing that tuple signature everywhere gets tedious, but everything that uses the data is external so there's no need for any methods. Do I typealias the tuple, make a struct, or does it not really matter? Tuples also have the unique ability to be trivially unwrapped into method parameters, so there's that. There's no shame in a methodless struct. Other than that, I think it's just a matter of style. If I bother to come up with a name for my typealiased tuple, I'm probably just going to make a struct anyway. edit: beaten like a named tuple
|
# ? May 27, 2015 03:33 |
|
Yeah my instinct was a struct, but I didn't know if the language had a different intent. Thanks.
|
# ? May 27, 2015 13:38 |
|
dupersaurus posted:Yeah my instinct was a struct, but I didn't know if the language had a different intent. Thanks. That's pretty much it. Tuples are nice for one-off aggregates, but yeah, a typealias is a pretty clear point at which you should be using a struct.
|
# ? May 27, 2015 18:34 |
|
How're folks handling functions in Enums? Basically, I'm trying to grasp how "big" I allow some of my enums to get. For example, I have an activity tracker: code:
code:
code:
|
# ? May 28, 2015 20:27 |
|
I don't see the benefit. You haven't actually reduced the amount of code at the call site or factored anything out.
|
# ? May 28, 2015 21:36 |
|
Perhaps that wasn't the best example ever. I guess I'm more curious to people's thoughts as to when enums should own responsibility of more than just their values.
|
# ? May 28, 2015 22:26 |
|
Doh004 posted:Perhaps that wasn't the best example ever. I guess I'm more curious to people's thoughts as to when enums should own responsibility of more than just their values. I'm struggling to come up with a convincing reason for the enum to have anything unrelated to its value. You can certainly have methods, computed properties, and so on, but I reckon they shouldn't involve much beyond the enum itself.
|
# ? May 29, 2015 00:34 |
|
pokeyman posted:I'm struggling to come up with a convincing reason for the enum to have anything unrelated to its value. You can certainly have methods, computed properties, and so on, but I reckon they shouldn't involve much beyond the enum itself. I could see that. Maybe for example I could do: code:
|
# ? May 29, 2015 02:38 |
|
I got another 'expression was too complex to be solved in reasonable time' compiler exception...code:
Also, it compiles fine if I do '$0 as Int', although you don't get any compiler warnings if you pass an array of non-Ints, and instead the app crashes...will this be possible in the future?
|
# ? Jun 3, 2015 13:49 |
|
Presumably it causes inference issues because the compiler starts by expanding the list of all the things that an Int can be initialised from. What you're trying to do, i.e. extend Array in a way that only applies to Arrays of things that can initialise an Int, isn't possible in Swift at the moment, and your code wouldn't compile even if it wasn't “too complex”. The right way for now is usually to made a function, instead of a method, that takes an array as an argument and has a suitable generic constraint.
|
# ? Jun 3, 2015 15:32 |
|
Consider doing one of the following.code:
I think I have the syntax right there... Sadly generic type constraints and extensions don't really mix yet in Swift.
|
# ? Jun 7, 2015 07:45 |
|
In this matter, I counsel patience.
|
# ? Jun 7, 2015 09:14 |
|
rjmccall posted:In this matter, I counsel patience. So excited. Have an awesome week.
|
# ? Jun 7, 2015 15:52 |
|
rjmccall posted:In this matter, I counsel patience. I am super excited; looking forward to meeting the Swift team.
|
# ? Jun 7, 2015 22:02 |
|
Wish I could be there!
|
# ? Jun 8, 2015 16:38 |
|
Congrats on open source, doods!
|
# ? Jun 8, 2015 19:17 |
|
Yeah, pretty thrilled about it. It's been a long time coming.
|
# ? Jun 8, 2015 19:24 |
|
Had to be a ton of work, too. Great stuff.
|
# ? Jun 8, 2015 19:28 |
|
Maintaining the port actually hasn't been too bad. It's scrubbing the repository that's going to be a pain, because I don't think we want to just cut a snapshot.
|
# ? Jun 8, 2015 19:31 |
|
Very cool news, congratulations rjmccall!
|
# ? Jun 8, 2015 20:00 |
|
Biggest applause break 2 years running
|
# ? Jun 8, 2015 21:01 |
|
Congrats; can't wait for the Platform SotU
|
# ? Jun 8, 2015 21:07 |
|
rjmccall posted:Maintaining the port actually hasn't been too bad. It's scrubbing the repository that's going to be a pain, because I don't think we want to just cut a snapshot. Ah, you still have to pass that stone.
|
# ? Jun 8, 2015 21:27 |
|
The Swift blog has a post on 2.0 with a summary of new things. try-catch has arrived. Edit: More on the Swift marketing page. Toady fucked around with this message at 22:13 on Jun 8, 2015 |
# ? Jun 8, 2015 21:51 |
|
rjmccall: would love to know more about why you chose Go-style defer over try-finally. I'd have expected the latter!
|
# ? Jun 8, 2015 22:01 |
|
|
# ? May 28, 2024 14:36 |
|
Defer puts the cleanup code next to the code creating the thing which needs to be cleaned up rather than as far away as possible (and is pretty useful even in the absence of exceptions).
|
# ? Jun 8, 2015 22:04 |