[swift-evolution] [Draft] Mixins

[Антон Жилин]

Thank you, I probably didn't care about the subject at that time, until
abstract classes proposal got serious.
I currently suggest that mixins can only be included directly at type
definition.
I don't think we will lose too much. Extending these possibilities might
follow the proposal *if* it gets accepted.

2016-02-28 3:47 GMT+03:00 Wallacy <wallacyf at gmail.com>:

> You are not alone, discursions like start a long time ago on Swift 1.1 on
> the old forum.
>
> I also have here on my desktop some proposals involving storage properties
> in protocols.
>
> The idea appears to be simple, but is hard to get a good design.
>
> Properties on Default Protocol Implementations
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/2996>
>
> Some quotes that can help here:
>
> -- Douglas Gregor  -- "
> Default implementations of functions don’t require per-instance state,
> while adding a stored property via a protocol extension does. Let’s step
> back to a simpler problem: stored properties in (non-protocol) extensions.
>
> In the existing language, one can only introduce stored properties in the
> primary definition of the type. That’s because, when we create an instance
> of that type, we need to know how much storage to allocate for that
> instance. So, right now, we don’t even allow, e.g.,
>
> struct MyStruct { }
> extension MyStruct { var storage: Int = 0 } // error: extensions may not
> contain stored properties
>
> class MyClass { }
> extension MyClass { var storage: Int = 0 } // error: extensions may not
> contain stored properties
>
> because, in the worst case, we don’t know about the storage required for
> the “storage” property until after we’ve allocated some instances of
> MyStruct or MyClass, and we can’t simply go back and resize those instances
> when we learn about the “storage” property. The “worst case” here could
> come about with shared libraries: put the MyStruct/MyClass primary
> definitions into an app, then put the extensions into a separate shared
> library. The app creates some MyStruct and MyClass instances, then loads
> the shared library, and now we have a problem: those instances have no
> storage for “storage.”
>
> We could relax the requirement to allow extensions in the same module as
> the primary definition of that type to introduce stored properties, because
> they’re compiled along with the primary type definition anyway. This
> doesn’t solve out-of-module extensions, of course.
>
> We could embed a pointer into each instance that points off to the stored
> properties for that instance. The pointer would refer to some
> lazily-allocated memory on the heap with that extra storage. However, this
> would either bloat every data structure by a pointer (including “Int”!) or
> have to be opt-in, neither of which are great. I don’t think there is any
> reasonable implementation for out-of-module stored properties in extensions
> of value types (struct/enum).
>
> For classes, where we have object identity, we could have a side table
> containing the stored properties (keyed on the object’s address). This is
> how Objective-C’s associated objects work, and it’s a reasonable module for
> out-of-module stored properties in extensions of classes.
>
> Getting back to stored properties in protocol extensions, the general
> feature isn’t implementable without having some mechanism for out-of-module
> stored properties in extensions of structs and enums, so you can limit it
> in a few ways:
>
> * Only allow them on class-bound protocols, where there is a reasonable
> implementation model
>
> * Allow them as default implementations within a protocol (not an
> extension of a protocol!); a type can conform to that protocol either by
> providing its own implementation of that property or somewhere where it is
> reasonable for the default implementation to inject a stored property into
> that context (e.g., on the primary type, within the same module as the
> primary type, or on a class).
>
> Either handles the example brought up in the discussion of abstract base
> classes.
>
> - Doug
> "
>
> -- Chris Lattner  -- "
>
> Hi Doug,
>
> Have you considered this similar-but-different approach?
>
> - Allow extensions on classes (only) within the same module/resilience domain as the class to add stored
> properties. This would keep them inline in the instance.
> - Allow protocols to have stored property declarations, introducing a new “protocol with storage”
> (PwS) concept.
> - Classes can directly conform to a PwS in its definition, or within an extension inside the same
> module/resilience domain.
>
> Just this would give many of the benefits of a full mix-in programming model.  People could define these
> protocols, and their local implementation of the type can benefit from them.  It doesn’t support
> retroactive mixin’ing, but that is probably a good thing.  I’m assuming that we don’t want to allow
> adding state to structs within a resilience domain, just because I don’t think that is actually a good
> thing to add to the programming model (other reasonable people will surely disagree).
>
> This base model could then be extended:
> - Structs could conform to a PwS in their definition, but not an extension.  We could optionally require the
> struct to redeclare the properties to improve readability of the struct, but it wouldn’t be required
> from an implementation perspective.
> - Classes could conform to a PwS across resilience boundaries, but wouldn’t get the state: they’d have
> to implement the storage requirement with a computed property.
> - We could introduce an “associated objects” property behavior that makes providing the computed
> property very straight-forward, using the out of band implementation approach of ObjC.
>
> The advantages of this approach I see are:
>
> 1) implementable, always a bonus.
> 2) keeps predictable performance.  You don’t get out “associated objects” overhead unexpectedly.
> All state is always stored inline.
> 3) retroactive mixins are possible, but explicit.
>
> The primary downside of this approach is that it introduces yet another weird protocol variant with
> limitations and behaviors, making the model more complicated.
>
> -Chris
>
> "
>
> Some of the challenges I'm having to write my proposal is to find a model
> that does not make the language much complex and still bring a direct
> benefit.
>
> Em sáb, 27 de fev de 2016 às 06:59, Антон Жилин <swift-evolution at swift.org>
> escreveu:
>
>> Some people opposed to Abstract Classes proposal (including myself) have
>> said that mixins could solve the problem better.
>> So I prepaired a proposal draft to add stored properties to protocols.
>> Here it is:
>> https://gist.github.com/Anton3/f0550922c1be0fc5447c
>>
>> P.S. I added a `mixin` keyword in the beginning, but we can opt to just
>> extend protocols, which I mention in "alternatives".
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160228/6185c9fa/attachment.html>