Re: why is this Swift initializer legal
Re: why is this Swift initializer legal
- Subject: Re: why is this Swift initializer legal
- From: Roland King <email@hidden>
- Date: Sun, 07 Jun 2015 10:15:59 +0800
> On 7 Jun 2015, at 10:01, Quincey Morris <email@hidden> wrote:
>
> On Jun 6, 2015, at 18:10 , Roland King <email@hidden <mailto:email@hidden>> wrote:
>>
>> Quincey may well be right and in the case of a class which has one single, no-arg, DI that DI is automagically added in by the compiler at the end of the method.
>
> After further thought, I’d say something stronger. In the scenario we’re talking about (the superclass has a single designated init, with no parameters), the subclass *must* call ‘super.init ()’. It’s the only possibility, and it’s absolutely required, so there’s no danger in the compiler doing it for you.
>
>> I rather hope that’s not true, Swift is already replete with little rules and oddities you have to know about
>
> I thought about this too, but many of these little rules and oddities are cases where writing something yourself is as much a Forced Move as the 'super.init ()’ above. It would be perfectly *logical* to make you write them yourself, so as to avoid “exceptional” syntax rules, but one of the annoying things about Obj-C is that we have to write lots and lots of stuff that the compiler already knows. Lots and lots and lots of stuff.
>
> In this case, it’s harmless. If you write the super call, it’s fine. If you omit it, there’s no possible danger. (If you subsequently change the superclass in a way that makes it dangerous, you’ll start getting errors.)
>
> It’s also useful, as well as harmless. There are plenty of real-life situations where you have class hierarchies that only have parameterless designated initializers. This convention allows you to leave them out all the calls to them. Plus, there’s a *default* parameterless designated initializer convention that may let you leave out all of the initializers completely. Again, since it’s safe, future-proof and convenient, I’d say better to have it than not.
>
Going to have to agree to disagree on this one. The rules about inherited initializers and cases you don’t need to write intializers at all make sense to me, even if I have to read them occasionally to remind myself. But if there’s a rule that a DI needs to call a superclass DI (if it has a superclass) then it should be like that in every class. I’d be happier if Xcode put up an error and offered to fix it by inserting the missing line, as it so often does, than just hiding it. If I could find a place it was documented in which cases the compiler does it for you I’d think ‘ugh’ but try to remember that rule too, I can’t find it documented anywhere, so I filed it.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden