class Person {
struct Address {
class Postcode {}
}
}
Postcode would be encoded as Contacts.Person.Address.Postcode. Since it is not possible to have two different types with the same identifier in the same namespace (i.e. an enum/a class/a struct with the same name at the same declaration level) the encoding would similarly be simple. May I proceed under that assumption or are there ABI stability issues I have yet to consider?
Yeah, that eventually ought to work. We're in the middle of setting up the layout of Swift metadata to make this kind of dynamic lookup easier to support.
-Joe
···
On Oct 27, 2016, at 6:54 AM, swizzlr via swift-dev <swift-dev@swift.org> wrote:
class Person {
struct Address {
class Postcode {}
}
}
Postcode would be encoded as Contacts.Person.Address.Postcode. Since it is not possible to have two different types with the same identifier in the same namespace (i.e. an enum/a class/a struct with the same name at the same declaration level) the encoding would similarly be simple. May I proceed under that assumption or are there ABI stability issues I have yet to consider?
This is somewhat intentional. While simple names can be encoded hierarchically like this, generics make everything more tricky. Consider a demangled name "Contacts.Person.Address<AddressKit.UnitedStates>.PostCode"—in this case not only is splitting on "." is no longer a reasonable thing to do, but there's not currently a way to get the type for 'Address' with a particular generic argument.
The Swift compiler and Foundation teams were a bit at odds here, trying to decide whether it would be appropriate to use Swift's current mangling scheme for encoded class names, or whether it would be better to pick something else. (This is what the Objective-C runtime currently does on Apple platforms, but that too could be changed, though we'd have to be careful about backward-compatibility.) IIRC at the time we decided it was best to implement the minimal thing that handles the common case—top-level non-generic types—and worry about the more complicated things later.
Jordan
···
On Oct 27, 2016, at 6:54, swizzlr via swift-dev <swift-dev@swift.org> wrote:
class Person {
struct Address {
class Postcode {}
}
}
Postcode would be encoded as Contacts.Person.Address.Postcode. Since it is not possible to have two different types with the same identifier in the same namespace (i.e. an enum/a class/a struct with the same name at the same declaration level) the encoding would similarly be simple. May I proceed under that assumption or are there ABI stability issues I have yet to consider?
Thanks all, I’ll take this info to try to come up with a draft proposal for encoding after having done deeper research into the ins and outs of the current options and decisions made.
Appreciate the kind and useful responses!
Tom
···
This is somewhat intentional. While simple names can be encoded hierarchically like this, generics make everything more tricky. Consider a demangled name "Contacts.Person.Address<AddressKit.UnitedStates>.PostCode"—in this case not only is splitting on "." is no longer a reasonable thing to do, but there's not currently a way to get the type for 'Address' with a particular generic argument.
The Swift compiler and Foundation teams were a bit at odds here, trying to decide whether it would be appropriate to use Swift's current mangling scheme for encoded class names, or whether it would be better to pick something else. (This is what the Objective-C runtime currently does on Apple platforms, but that too could be changed, though we'd have to be careful about backward-compatibility.) IIRC at the time we decided it was best to implement the minimal thing that handles the common case—top-level non-generic types—and worry about the more complicated things later.
Jordan
> On Oct 27, 2016, at 6:54, swizzlr via swift-dev<swift-dev at swift.org>wrote:
>
> Swift Foundation has an incomplete implementation of NSClassFromString/NSStringFromClass (link: https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObjCRuntime.swift#L230-L282\) due to a lack of a standardised method of encoding nested Swift classes, nor other Swift types.
>
> I would think that given
>
> module Contacts
>
> class Person {
> struct Address {
> class Postcode {}
> }
> }
>
> Postcode would be encoded as Contacts.Person.Address.Postcode. Since it is not possible to have two different types with the same identifier in the same namespace (i.e. an enum/a class/a struct with the same name at the same declaration level) the encoding would similarly be simple. May I proceed under that assumption or are there ABI stability issues I have yet to consider?
>
> Tom
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev