A couple of code conventions

[Patrick Robertson]

I’ve been meaning to mention these few things for a while, I think we should switch in QS at some point:

1. Use dispatch_once for singletons. See this SO for more info. Basically, dispatch_once is thread safe and kinda more obvious what it’s for.

2. For our init and convenience methods, originally the recommended procedure was to use `id` as the return type, but now Clang has instancetype - something I see Etienne has already started using ;-)

It makes our code uncompilable for older Clang versions, but I don’t think that’s too much of a problem - I think Henning lost the ability to compile a while ago? :(

Oh, and an NSHipster link because you all like being a hipster ;-)

http://nshipster.com/instancetype/

The main advantage of this I think is that we won’t have to do stupid casting between (QSBasicObject *) and (QSObject *) which we’re having to do in a few places at the moment.

Are there any other code conventions/nuggets that people have picked up recently that we should use in QS

[Etienne Samson]

Le 30 nov. 2013 à 03:09, Patrick Robertson <robertso...@gmail.com> a écrit :

> I’ve been meaning to mention these few things for a while, I think we should switch in QS at some point:
>
> 1. Use dispatch_once for singletons. See this SO for more info. Basically, dispatch_once is thread safe and kinda more obvious what it’s for.

+1, unless there's a good reason not to ;-).

> 2. For our init and convenience methods, originally the recommended procedure was to use `id` as the return type, but now Clang has instancetype - something I see Etienne has already started using ;-)
> It makes our code uncompilable for older Clang versions, but I don’t think that’s too much of a problem - I think Henning lost the ability to compile a while ago? :(
> Oh, and an NSHipster link because you all like being a hipster ;-)
> http://nshipster.com/instancetype/
> The main advantage of this I think is that we won’t have to do stupid casting between (QSBasicObject *) and (QSObject *) which we’re having to do in a few places at the moment.

+1.

> Are there any other code conventions/nuggets that people have picked up recently that we should use in QS

The dot-syntax thing I've been unintentionally doing ?

Cordialement,
Etienne Samson
--
samson....@gmail.com

[Etienne Samson]

Another one (that I just pushed to the `leaks` branch), I'd prefer that we use __bridge/__bridge_transfer/__bridge_release instead of the CF functions (I find the CF names most confusing).

Regards,
Etienne Samson
--
samson....@gmail.com

[Patrick Robertson]

> Another one (that I just pushed to the `leaks` branch), I'd prefer that we use __bridge/__bridge_transfer/__bridge_release instead of the CF functions (I find the CF names most confusing).

Agreed. I meant to mention this before as well. CFBridgingxxx is not as clear as the so called ‘casting’ I think.

[Etienne Samson]

Le 30 nov. 2013 à 17:10, Patrick Robertson <robertso...@gmail.com> a écrit :

> > Another one (that I just pushed to the `leaks` branch), I'd prefer that we use __bridge/__bridge_transfer/__bridge_release instead of the CF functions (I find the CF names most confusing).
>
> Agreed. I meant to mention this before as well. CFBridgingxxx is not as clear as the so called ‘casting’ I think.

(Note: that's __bridge_retained, not __bridge_release above)

Yep, at least the casts don't look reversed : if you want to take a "Copy"-returned CF object and give it to ARC, you have to call CFBridgingRelease (a.k.a __bridge_transfer), which doesn't make sense.