C99 Struct Initialisers

[dannygreg]

Document a preference for verbose struct initialisers rather than helper functions. These are easier to read and allow structs to be initialise with any sub-structs rather than having to use their members explicitly.

[exalted]

@dannygreg I’m so curious, why?

[dannygreg]

Sorry, I should possibly have been more explanatory in my description.

Essentially, if I am reading CGRectMake(12.0, 52.0, 26.0, 15.0) I have to have knowledge of what each parameter is. Obviously CGRectMake() is a pretty common usage so maybe not the best example, but it's the same thinking of method's "named parameters". It's more verbose, but it's more legible. This being Objective-C verbosity is nothing to be scared of 😄

Another great positive is that if structs are compositions of other struct types we can mix and match what we use to initialise it. For example, a CGRect is composed of a CGPoint and a CGSize. Say we have already have the size, we can do this:

{ .origin.x = 5.0, .origin.y = someVariable, .size = sizeVariable }

Which is more convenient than being forced to break everything up into individual values for a function like CGRectMake().

Hopefully that cleans things up, I feel incapable of effectively writing English today… probably need more ☕

[exalted]

Ummm… What if, say CGRect’s, internals change however? I expect Apple would CGRectMake keep workin’, whereas explicit initialization could probably break at some point.

P.S.: if I sound like arguing just for the sake of it, then ignore… 😕

[dannygreg]

P.S.: if I sound like arguing just for the sake of it, then ignore…

Absolutely nothing wrong with argument, as long as it's rational and on topic. In this case it is definitely both 😄

Ummm… What if, say CGRect’s, internals change however? I expect Apple would CGRectMake keep workin’, whereas explicit initialization could probably break at some point.

Fair point, but as these will be public structs any change in them, which would break this, would would also break any direct access to members (such as using . or ->) Apple basically can't change them for fear of breaking everything.

If a struct is declared publicly, it's fairly safe to assume it won't change.

[exalted]

👍

[aroben]

s/NSRect/CGRect/ :trollface:

[exalted]

That’s a funny face tho 😄

@aroben what’s that “repo collab" label–thing on your name please?

[dannygreg]

Also some weird spacing in there, nice catch @aroben!

@exalted: it means he is a collaborator on the repository (he has commit access).

[exalted]

@dannygreg how come I don’t get those in my organization repos? Maybe only external people see those labels? Not sure...

[jspahrsummers]

Ummm… What if, say CGRect’s, internals change however? I expect Apple would CGRectMake keep workin’, whereas explicit initialization could probably break at some point.

@exalted Designated initializers (which is how C99 refers to them) would only break if the names of the fields changed – they don't depend on the specific order or layout of the fields, if that's what you meant.

[jspahrsummers]

We probably don't need to show this example if we have the above (and it's right under the bullet point).

[dannygreg]

Agreed (if we add the example as suggested below).

[jspahrsummers]

🎒

[dannygreg]

🏉

[jspahrsummers]

🏈