[swift-evolution] stored properties in extensions (was: associated objects)

[Jay Abbott]

I agree Karl, especially the bit about the difficulty of implementation
being the limiting thing here.

I think the language devs must have some idea how this will work, but don't
seem to want to share/discuss it at the moment. I was hoping for some
feedback about my implementation ideas - whether they are along the right
lines, or way off, or not necessary (because the implementation strategy is
already known). Perhaps this the wrong list for that kind of discussion?

Anyway, I was thinking some more and I had another idea about
implementation. This could be very useful for maintaining binary
compatability in other areas too.

Implementation idea No. 4:

The basic concept is that the dynamic linker would fixup the offsets as
well as relocating the addersses, allowing the size of objects (and maybe
structs?) to change at link-time. The process might be something like this:

* References to members defined in extensions would compile to have an
offset symbol instead of a value - so they can be fixed up later
* The linker would scan all the shared objects that are referenced (and
thus might get linked)
* Build up a list of Stored Properties In ExtensionS (SPIES, muhahaha) for
each class.
* Append the extra fields (increase the size the class), decide where each
member goes in the extended layout and fixup the offsets
* Carry on with normal relocation

There are quite a few assumptions in the above, and probably quite a few
misunderstandings about how things work on my part too (I'm not an expert
at this), however I think it should work in principle. Some questions about
my assumptions: Can linker know in advance all the potential modules that
could be linked, or is this done more lazily and it only knows about what
it's linking right now? Is it ok for the size to change - I don't know if
it's a static sizeof() or if it could be (or already is) stored in the isa?

Would love to hear back from anyone who is familiar with the code if this
sounds viable or not. I'd love to go digging in there myself (I've tried a
few times but got lost) but I don't have time at the moment.


On Tue, 11 Oct 2016 at 08:19 Karl <razielim at gmail.com> wrote:

>
> > On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Right. The question is whether we *need* to add stored properties
> out-of-module, and what the use case for that is. To me it seems that
> adding them in-module is by far the more common use case, for the purposes
> of implementing protocols.
> >
> > At any rate, the rewrite option would be a great addition to Swift
> regardless of what our answer to the first question is.
> >
> > Charles
>
> I actually think out-of-module is the more common and important case. If
> you’re using a types from an external framework, it’s strange that you can
> retroactively add functionality but not additional data. That limitation,
> AFAICT, is purely due to implementation. Some well-constructed frameworks
> will allow you to add stored data to the types being used by subclassing.
> Not all are so well constructed, and as we have more and more value-types
> subclassing is not going to be a solution.
>
> You can add stored properties to objects in Python, which is one of the
> really great things about it. If you need to add a stored property to track
> some additional state you layer on top of a framework’s components, it’s
> staggering how easy it is - you don’t even need to define any new types.
>
> I personally think it’s important for Swift as a scripting language to
> have this ability - for value-types as well as classes, by default. We
> could optimise it away completely for types which aren’t public, and you
> should be able to explicitly declare a type non-extendable (similar to
> declaring it non-subclassable with ‘final’) to opt-out. I’m sure it will
> never happen, but there you go.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161011/7b70dca2/attachment.html>