> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution
> <firstname.lastname@example.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.
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.
swift-evolution mailing list