The coder/programmer/software engineer debate seems to be rising from the undead again

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

First, a confession - I actually occasionally call myself a coder, but in a tongue in cheek, post-modern and ironic way. Heck, it does make for a good blog title and license plate. Nevertheless, with all the recent “coding schools” cropping up all over the place - at least if you are in the Bay Area - it does seem that being able to code in the context of a reasonably sought after web technology without much further formal training is the path to new, fulfilling careers and of course untold riches in an economy where recent graduates in all fields have problems finding work.

Subclassing Objective-C classes in Swift and the perils of Initializers

Pete Barber from C#, C++, Windows & other ramblings

--- Begin update

1. The post below applies to Xcode 6 Beta 2. With Beta 3 & 4 the relationships between the Swift and Objective-C regarding the calling of super class initializers has been formalized.

1a. A Swift class can have multiple non-convenience initializers but in this case they must all property initialize any properties. Also, a non-convenience initializer cannot invoke another initializer, i.e. it cannot call self.init(...)

1b. When calling an Objective-C any initializer can be called but unlike what happened in Beta 2 if the initializer invoked is not the Objective-C 'designated' initializer and thus calls it this DOES NOT now result in a virtual like call to an initializer with that signature in the subclass, i.e. the main problem that led to the writing of this blog post.

2. If you want to subclass an SKSpriteNote in Beta 4 the following StackOverflow post shows how.

3. It seems that for some OS classes, in my case SpriteKit either Apple directly or some Xcode magic now provides a shim Swift wrapper of the Objective-C interface (the one for SKSpriteNode has a comment with a date of 2011 but when attempting to "show in Finder" nothing happens). As such all the initializers for SKSpriteNode are marked as convenience except for the 'designated' initializer, e.g.

class MySpriteNode : SKSpriteNode {}

3a. This is now essentially a Swift only project with the MySpriteNode now deriving from SKSpriteNode which is a Swift class. As such the Swift rules must be followed. This means that any convenience initializers in MySpriteNode can only call non-convenience initializers for MySpriteNode and these MUST in turn call a non-convenience initializers in the superclass. In the case of SKSpriteNode there is a only a single designated initializer which is:

   /**
     Designated Initializer
     Initialize a sprite with a color and the specified bounds.
     @param texture the texture to use (can be nil for colored sprite)
     @param color the color to use for tinting the sprite.
     @param size the size of the sprite in points
     */

    init(texture: SKTexture!, color: UIColor!, size: CGSize)

Therefore from a derived class it's impossible to use the super class convenience methods which is what Swift demands but is a shame as it often means re-implementing similar code in the derived class, as per the StackOverflow link.

It's not perfect by any means but it's a lot more consistent than Beta 2. I don't (yet) understand where the magic shim comes from and this is update is based on Beta 4 whereas of writing Beta 5 has just been released!

--- End update

As a way to learn Swift I decided to have a play with Sprite Kit. One of the first things I did was to create a subclass of SKSpriteNode. This has a very handy initializer:

init(imageNamed name: string) (in Swift)
-(instanceType)initWithImageNamed:(NString*)name (in Objective-C)

I then derived from this resulting in:

class Ball : SKSpriteNode
{
    init()
    {
        super.init(imageNamed: "Ball")
    }
}

and added it to my scene as follows:

var ball = Ball()
ball.position = CGPoint(x:CGRectGetMidX(self.frame), y:CGRectGetMidY(self.frame))
self.addChild(ball)

Having successfully written similar code using SKSpriteKitNode directly:

var ball = SKSpriteNode(imageNamed: "Ball")
ball.position = CGPoint(x:CGRectGetMidX(self.frame), y:CGRectGetMidY(self.frame))
self.addChild(ball)

I was expecting it to work. However I received the following runtime error:

fatal error: use of unimplemented initializer 'init(texture:)' for class 'Ploing.Ball'

The odd thing was that it was complaining about the lack of initializer in the Ball class. Why would calling a base class initializer result in a call back to the derived class? I wasn't sure but to work around this I decided to add the missing initializer:

init(texture: SKTexture!)
{
    super.init(texture: texture)
}

Having duly done this I then got the next error:

fatal error: use of unimplemented initializer 'init(texture:color:size:)' for class 'Ploing.Ball'

Ok, same process add that one to the Ball class. 

init(texture texture: SKTexture!, color color: UIColor!, size size: CGSize)
{
    super.init(texture: texture, color: color, size: size)
}

That time it worked but I was puzzled as to why. What seems to be happening is that the derived class is calling the non-designated initializer in the super class which is then calling the designated (or another non-designated one in between). However, when this initializer is called rather than calling the super class implementation it calls one in the derived class, whether it exists or not. In the case of Ball they didn't hence the error.

It turns out that in the middle of the the Initialization section of the The Swift Programming Language there is the following:

Initializer Inheritance and Overriding
Unlike subclasses in Objective-C, Swift subclasses do not not inherit their superclass initializers by default. Swift’s approach prevents a situation in which a simple initializer from a superclass is automatically inherited by a more specialized subclass and is used to create a new instance of the subclass that is not fully or correctly initialized.
If you want your custom subclass to present one or more of the same initializers as its superclass—perhaps to perform some customization during initialization—you can provide an overriding implementation of the same initializer within your custom subclass.
This explains it. Basically, in Swift, initialization methods work like virtual functions in fact super virtual functions. If a super class initializer is invoked and that in turns calls another initializer (designated or not) then it forwards the call to the derived class. The upshot of this seems to be that for any derived class in Swift it would need to re-implement all of the super classes initializers or at least any which may be invoked from the the other initializers.

Time for some experiments

I therefore set out to confirm this with a simple Swift example:

class Foo
{
    var one: Int;
    var two: Int;

    init(value value:Int)
    {
        self.init(value: value, AndAnother:7)
    }

    init(value value:Int, AndAnother value1:Int)
    {
        one = value;
        two = value1;
    }

    func print()
    {
        println("One:\(one), Two:\(two)")
    }
}

class Bar : Foo
{
    init()
    {
        super.init(value:1);
    }
}

let bar = Bar()
bar.print()

This wouldn't compile. 

Designated initializer for 'Foo' cannot delegate (with 'self.init'); did you mean this to be a convenience initializer?
Must call a designated initializer of the superclass 'Foo'

Whereas in Objective-C the designated initializer is effectively advisory, in Swift it's enforced. If a initializer isn't marked with the convenience  keyword then it seems (at least during compilation) all initializers are treated as being the designated initializor and not at the same time. In this case the compilation failed as there was no designated initializer for Bar.init to call and as Foo.init(value value:Int) wasn't marked as a connivence initializer it was assumed to the designated one and is thus forbidden from calling another initializer in its own class; somewhat paradoxically.

These two rules prevent issues that occur with Objective-C's advisory initializer. All but the designated initializer must be prefixed with the convenience keyword. Secondly this is the only initializer permitted to call the super class initializer meaning all the the convenience initializers can only (cross) call other convenience or the designated initializer for their class. Following these rules gives a working example:

class Foo
{
    var one: Int;
    var two: Int;

    convenience init(value value:Int)
    {
        self.init(value: value, AndAnother:7)
    }

    init(value value:Int, AndAnother value1:Int)
    {
        one = value;
        two = value1;
    }

    func print()
    {
        println("One:\(one), Two:\(two)")
    }
}

class Bar : Foo
{
    init()
    {
        super.init(value: 7, AndAnother: 8)
    }
}

let bar = Bar()
bar.print()

Which gives the results:

One:7, Two:8

It also completely bypasses the convenience method of the superclass rendering it useless for calling from a derived class.

As for explaining the original problem this doesn't help either as the new rules prevent the problem. Herein lies the clue though. It suggests the problem is not with Swift classes subclassing other Swift classes but when a Swift class subclasses an Objective-C class.

Subclassing Objective-C from Swift

Time for another experiment but this time using a base class written in Objective-C:

Base.h

@interface Base : NSObject

-(id)initWithValue:(NSInteger) value;
-(id)initWithValue:(NSInteger) value AndAnother:(NSInteger) value1;
-(void)print;

@end

Base.m

#import "Base.h"

@interface Base ()
@property NSInteger one;
@property NSInteger two;
@end

@implementation Base

-(id)initWithValue:(NSInteger) value
{
    return [self initWithValue:value AndAnother:2];
}

-(id)initWithValue:(NSInteger) value AndAnother:(NSInteger) value1
{
    if ([super init])
    {
        self.one = value;
        self.two = value1;
    }
    
    return self;
}

-(void)print
{
    NSLog(@"One:%d, Two:%d", (int)_one, (int)_two);
}

@end

main.swift

class Baz : Base
{
    init()
    {
        super.init(value: 7)
    }

    init(value value:Int, AndAnother value1:Int)
    {
        super.init(value: value, andAnother: value1);
    }
}

var baz = Baz()
baz.print()

Looking at Base it's obvious that the desginated initializer is initWithValue:(int)value AndAnother:(int)value1 whereas Baz is calling a 'convenience' initializer. This compiles happily but when run gives the following error:

fatal error: use of unimplemented initializer 'init(value:andAnother:)' for class 'Test.Baz'

This is the same type of error as in the original SKSpriteNote sample. Here, Baz's initializer is successfully invoking the Base.initWihValue:(int) value but when it invokes Base's designated initializer this is when the super virtual functionality of the initializers comes into play and an attempt is made to call this non-existent method on Baz. This is easily fixed by adding that method such as it calls the super class method as in:

class Baz : Base
{
    init()
    {
        super.init(value: 7)
    }

    init(value value:Int, AndAnother value1:Int)
    {
        super.init(value: value, andAnother: value1);
    }
}

Giving the result:

2014-06-07 17:40:18.632 Test[47394:303] One:7, Two:2

Alternatively and staying true to the Swift way the parameterless intializer which is obviously a convenience initializer should be marked as such. This then causes a compilation failure as this is now forbidden from calling the super class initialzer and instead must make a cross call to the designated initializer giving the following code:

class Baz : Base
{
    convenience init()
    {
        self.init(value: 7, AndAnother: 8)
    }

    init(value value:Int, AndAnother value1:Int)
    {
        super.init(value: value, andAnother: value1);
    }
}

Which gives the result:

2014-06-07 17:40:46.345 Test[47407:303] One:7, Two:8

This differs from the previous version as the connivence initializer now calls the designated one within Baz meaning the  -(id)initWithValue:(NSInteger) value is never called which is why the second value is nolonger 2.

Conclusion

Whilst this explains the behaviour I was seeing when subclassing SKSpriteNode and by providing a mirror of its initializers without marking any as convenience it solves the problem of using the convenient init(imageNamed name: string) method it doesn't do so particularly elegantly nor in a fully Swift style; as it leaves the class with a set of initializers none of which are marked convenience.

A designated initializer could be specified by marking all but the init(texture texture: SKTexture!, color color: UIColor!, size size: CGSize) method as convenience and having them cross call this one. However this would prevent the direct calling of init(imageNamed name: string) which is a lot more convenient than the other methods. 

Ironically, whilst Swift formalizes the designated initializer concept and it looks like it will work well for pure Swift code it can be somewhat inconvenient when subclassing Objective-C classes.

P.S. For those of us who have trouble spelling the keyword convenience is far from convenient. A keywoard to mark the designated initializer may well have been more convenient and probably easier to spell! 

Initial thoughts on Swift

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

Like pretty much every other programmer with a Mac, I’m currently looking at Swift. Will I write anything but toy programs in it? I don’t know yet - I don’t really write any Mac-ish software on my Mac, just unix-ish programs. If Swift doesn’t escape the OS X and iOS ecosystems it’ll be a nice exercise in a neat language that’s not really that relevant to the world at large, or at least to my part of the world at large.

Videos from C++ track on NDC 2014

olvemaudal from Geektalk

As the chair for the C++ track on NDC Oslo, I am happy to report that the C++ track was a huge and massive success! The C++ community in Norway is rather small so even if NDC is a big annual conference for programmers (~1600 geeks) and even with names like Nico, Scott and Andrei as headliners for the track, I was not sure how many people would actually turn up for the C++ talks. I was positively surprised. The first three sessions was packed with people (it was of course a cheap trick to make the three first sessions general/introductory on popular topics). All the other talks were also well attended. The NDC organizers have already confirmed that they want to do this next year as well.

NDC Oslo is an annual five day event. First two days of pre-conference workshops (Andrei did 2 days of Scalable design and implementation using C++) and then 9 tracks of talks for three full days. As usual, NDC records all the talks and generously share all the videos with the world (there are 150+ talks, kudos to NDC!).

I have listed the videos from the C++ track this year. I will also put out a link to the slides when I get them. Enjoy!

Day 1, June 4, 2014

  • C++14, Nico Josuttis (video)
  • Effective Modern C++, Scott Meyers (video)
  • Error Handling in C++, Andrei Alexandrescu (video)
  • Move, noexcept, and push_back(), Nico Josuttis (video)
  • C++ Type Deduction and Why You Care, Scott Meyers (video)
  • Generic and Generative Programming in C++, Andrei Alexandrescu (video)

Day 2, June 5, 2014

  • C++ – where are we headed?, Hubert Matthews (video)
  • Three Cool Things about D, Andrei Alexandrescu (video)
  • The C++ memory model, Mike Long (video, slides)
  • C++ for small devices, Isak Styf (video)
  • Brief tour of Clang, Ismail Pazarbasi (video)
  • Insecure coding in C and C++, Olve Maudal (video, slides)
  • So you think you can int? (C++), Anders Knatten (video)

With this great lineup I hope that NDC Oslo in June has established itself as a significant annual C++ event in Europe together with Meeting C++ Berlin in December and ACCU Bristol in April.

Save the date for NDC next year, June 15-19, 2015. I can already promise you a really strong C++ track at NDC Oslo 2015.

A final note: Make sure you stay tuned on isocpp.org for global news about C++.

Someone is building a BBC Micro emulator in Javascript

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

For those of us who remember when the BBC Micro was the home computer with the fastest Basic implementation available, a long time ago, and was pretty legendary in home computing circles in Europe. It didn’t sell that much outside of the UK, mostly because of its price. It was also the target system for the original implementation of Elite. Matt Godbolt is building an emulator in JavaScript. First post of his series can be found here.