0

Define the following complex object hierarchy below into a playground in XCode:

class Foo {
    var name: String

    required init(name: String) {
        self.name = name
    }
}

class Bar: Foo {
}

class Baz: Bar {
}

Creating instances of these classes yields confusing results:

var foo = Foo(name: "Hello") // renders as {name: "Hello"}
var bar = Bar(name: "Hello") // renders as {{name: "Hello"}}
var baz = Baz(name: "Hello") // renders as {{{...}}}

The results make it appear that the bar and baz are objects composed of instances of their parents, rather than inheriting from them.

Is this just the way XCode renders these objects, or is their structure not as I would expect?

RRP
  • 328
  • 8
  • 11
  • what do you mean? they are inheriting the `name` field from their parent. that's how inheritance works – Abdul Ahmad Jul 13 '15 at 05:35
  • @Abdul Ahmad: Yes - the `name` property is not the problem. My confusion is because each level of inheritance is wrapped in `{}`, making it appear to be a composition of objects. I would expect each of `foo`, `bar` and `baz` to render the same (as `{name: "Hello"}`) – RRP Jul 13 '15 at 05:39
  • Oh ok... well, why does that matter? as long as the objects behave correctly when you create your application, you should be good to go right – Abdul Ahmad Jul 13 '15 at 05:40
  • @Abdul Ahmad: It matters because I don't understand it, and I want to know why it's not behaving as I expect :) – RRP Jul 13 '15 at 05:42
  • what do you mean by renders? if you do `println(name)` it should just say `Hello` – Abdul Ahmad Jul 13 '15 at 05:43
  • Perhaps XCode wants to tell you that the class which you have instantiated inherits from some parent class and that this instance can be stored in a reference of parent class as well. – Krishna Jul 13 '15 at 05:43
  • @Abdul Ahmad: A playground automatically renders a representation of a variable in the sidebar. Again, it's not the `name` property that concerns me here, it's the nested `{}` – RRP Jul 13 '15 at 05:56

2 Answers2

0

I think this is the way inheritance (and protocol adoption) works in Swift under the water. Probably just a C structure which holds a pointer to an "embedded" structure of the same kind.

E.g. if you do the same sort of code in normal project and debug it, then you will see that each level of inheritance and protocol adoption is "wrapped" around the previous one, with each level providing only those methods/properties that are defined by it.

Not directly related, but still interesting to read: https://stackoverflow.com/a/31325662/1542569

Swift is implemented in C. You can see an overview of one person's analysis here: https://github.com/rodionovd/SWRoute/wiki/Function-hooking-in-Swift

With Swift going open-source, I imagine this question will be answered more completely at that point.

Community
  • 1
  • 1
0x416e746f6e
  • 9,872
  • 5
  • 40
  • 68
0

What you see is just a default description and it reflects the fact that superclasses are in place.

This default description has already changed in Xcode 7.

You can customise it. If you like going in more details, you could investigate how reflect and Mirror works.

In short the mirror of your subclasses keeps (and has to) track of superclass. Thus Baz has a superclass in its mirror which is a Bar and then Bar has a superclass in its mirror which is Foo. That's why in Xcode 6 you see {} encapsulation for each level of subclassing.

Hope this helps

Matteo Piombo
  • 6,688
  • 2
  • 25
  • 25
  • 1
    Your answer led me to http://nshipster.com/mirrortype/ which further demonstrates your point. Many thanks Matteo, much appreciated. – RRP Jul 13 '15 at 09:17