Advertise here

Advertise here

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


BrianSlick · Treadmill Desk Ninja · @ @ @ @ @ @ @ @


Last Active
Tutorial Authors, Registered Users
  • Re: Swift Conventions - Change for Change Sake?

    I say this neither as a fan of Swift nor as someone who would have a reason to know the real answer. But I have generally found that when I sit and really think about the things I don't like about it, I do generally come up with an explanation that makes sense, even if I don't agree with it.

    For example, let vs var drives me up the wall. Seems like something the compiler should be able to figure out for me. But, when you realize that "let" == "immutable" and "var" == "mutable", and you realize there are many entire classes in Foundation that won't need to exist in Swift simply because of that difference (ex: NSArray vs NSMutableArray), ok, I can see some reasons for requiring it.

    I will guess that on a whiteboard somewhere several years ago, someone wrote out what they consider to be the smallest possible way to define a variable. And that would be:
    let value = 12.0

    ...using type inference as you noted. With the possible exception of "let", there really isn't much else you can remove while having a useful line of code. Ok, but in some circumstances, the compiler won't be able to make that inference, and we'll have to show a type somewhere. The question then becomes where.

    So, what importance does the order of items left-to-right matter? What do we want to see first, then next, then next, and so on? Years and years of C (and derivative) programming has hammered into us that the type should be first. But why? That was simply someone's decision 40 years ago. (Possibly a good decision with some technical backing, but a decision nonetheless). If we place it first again, then that's going to look REALLY odd with let or var.
    Float let value = 12.0

    Now my variable name looks like "let", and I have no idea what "value" is. So that's no good. Once we decide that type will not be first - at best it will be second after let or var - then what difference does it make where it is?
    let Float value = 12.0
    let value Float = 12.0
    let value = Float 12.0
    let value = 12.0 Float

    Is one inherently better than the other? It probably can't be on the right side of the =, since we still want the ability to define a variable with a type without necessarily defining a particular value right at this moment. (Ex: properties) Years and years of muscle memory want us to see the type before the name, but is that truly better?

    How about this, for the OCD amongst us that can be kinda picky with variable declarations:
    NSString *variable1 = ...
    NSString *variable2 = ...
    NSString *variable3 = ...
    CGFloat variable4 = ...
    CGFloat variable5 = ...
    CGFloat variable6 = ...

    Crap, I just changed my mind, and variable5 should now be a string. Well I can't just do this like an animal:
    NSString *variable1 = ...
    NSString *variable2 = ...
    NSString *variable3 = ...
    CGFloat variable4 = ...
    NSString *variable5 = ...
    CGFloat variable6 = ...

    *shudder* Now I have to move code around, maybe rename some things, just because I think that the type is more important than the variable name itself.

    Instead, Swift's designers elected to make the variable name more important than the type, further reinforced by how badly they don't want you to actually have to provide the type. (Side note: I personally feel this places a much greater burden on reading the code in exchange for typing less code; your brain has to make the same inferences the compiler does, which means you have to pay that much more attention when you're reading code.)
    let variable1 = "A"
    let variable2 = "B"
    let variable3: String = "C"
    let variable4 = 5.0
    let variable5 = "Dammit"
    let variable6: Float = 15.0

    Maybe this encourages grouping variable definitions by purposes instead of by type. And maybe it keeps me from shuffling code around when I change my mind about a type.

    And since one of the design choices was to be able to omit the type if possible, what would the remaining code look like when it is still needed?
    let variable1 = "A"
    let variable2 = "B"
    let String variable3 = "C"
    let variable4 = 5.0
    let variable5 = "Dammit"
    let Float variable6 = 15.0

    Is this inherently better for reading? I'm not so sure. So if the premise is "we don't want you to have to provide a type unless it is absolutely necessary", then I don't think I can really find fault with where they chose to place the optional notation.

    As I type this, I'm forming the opinion that the line of thinking is much the same for function definitions. Why is the very LAST thing that a function will do - return a value (or not) - the very FIRST thing I have to read about in the definition? Seems like what the method does, which should hopefully be nicely spelled out in the name of the method, is the first thing that should be there. Here, they muddied the waters a bit, because we went from "-" or "+" to "func" which is more to read, and then we further mess things up with "public" and "override" and probably a bunch of others that are all in the way of me reading what the name of the method is. But otherwise, other than, again, many many years of muscle memory telling me that the return type should be first, is there really an inherent reason that is a better approach?

    I'll make a guess that when returning a block, that'd be a bit of a mess to read if listed first. And probably somewhere along those lines is where the answer is. In some particular scenario, returning some obscure type really made a mess of readability when it was listed first, so they elected to move it last, to preserve or reinforce the importance of the method name itself. And when you consider the way things can be shortened or removed ("Void" >> () >> omitted), how does that impact the readability at the beginning vs the end compared to other functions? I'll make a guess that rather than making a blanket decision early on (either way, front or back), they listed out a bunch of these crazy scenarios and decided what would look best for most or all of them.
  • Re: no more NSManagedObject??

    They are moving away from the use of pch files. The newer project templates don't create them. The point is to import only what you need into any given file, rather than import EVERYTHING into EVERY file.
  • Re: How do you switch between view controllers?

    You could present a modal. But these are the kinds of decisions one makes at the beginning of the app development process.
  • Re: Titles Not Working

    The title property only gets applied to the immediate parent container controller. So for your 3 views, the immediate parent is the tab bar controller. You should see the self.title value shown in the tabs at the bottom.

    You should not put a tab bar controller inside a navigation controller. The tab bar controller should be the root, and then any tab that needs navigation should have its own navigation controller. This means you would have 3 navigation controllers in this example. Then you will be able to see the title at the top, set from within each view controller.

    To answer your specific question, yes you can make it work so that you can set the title of a single 'master' navigation controller from anywhere in the app. But no, you will not be going through self.title or self.navigationItem to make it happen, with this particular structure.
  • Re: BTIKit

    Tander wrote: »
    Do you have any good resources that I could learn more from with regards to creating test cases and using them effectively?

    Test-Driven iOS Development
    Tander wrote: »
    Also - do you know if it is difficult to implement tests in an existing project or is that too difficult?

    You can add them at any time. The vast majority of my code here existed long before I knew anything about tests.