On Thu, 21 Apr 2016, David Waite wrote:
Think of a Trait as providing a consumable set of functions. Now imagine that
we're combining the collective declarations of 1..N Traits all together,
consumed by a Class or Value Type (or Protocol!) in a predicable and safe way
(flattening: see the first Traits white paper).
extensions give us something trait-like, but with only one, non-opt-in
implementation and usually per protocol. I’d imagine a true trait system to
allow for more specific default implementations of Sequence, for example.
Exactly, Sequence protocol requirements could be met and provided directly by any
Trait(s) consumed by the protocol as default implementation(s), or consumed by a Class or
Value Type to partially or fully meet its protocol conformance requirements.
Fine-grained Traits of behaviour could be consumed in many different contexts, so it's
similar in some respects to AOP in that the code relating to that "aspect" or
behaviour is centralised into a composable entity which any class, value type or protocol
could consume and use.
with a Trait being a closure, where _only private_ data Properties can be
declared, providing 1..N function implementations. It could conform _towards_
a Protocol (partial to full conformance), and also be dependent upon other
names Traits, which would be consumed in parallel as a first-class citizen with
the Trait that depends on it.
Traits typically cannot declare fields/state. Is this not where you start to
cross over to Mixins?
The Stateful Traits papers have explored the issues with introducing state on
top of behaviour, but a simple solution to avoid this complexity is to not
allow state period, or keep all state private to the Trait and never visible to
any Trait consumer. I wouldn't necessarily mandate that Traits for Swift
should or could deal with state, they could be method-only behaviours and
side-step these issues entirely, declaring their own requirements in terms of
state that the consumer must provide, for example, or adherence to a protocol
that the consumer must satisfy.
I attempted to model this (today) via delegates for behavioral dependencies on
traits and self-wiring, but this creates issues with value type copying and
circular references in reference types. For that reason, I didn’t feel it was
appropriate to make a formal trait proposal until more definition toward
behaviors (e.g. Joe Groff’s property behaviors) or macros were in the
discussion.
I'll do some reading - was this a previous swift-evolution thread? I've not
started looking at Swift's own implementation, so I haven't thought out exactly
how they could be implemented, but on the surface at a syntactic and feature
level it seems like a good fit for Swift and a perfect complement to protocols,
enabling fine-grained code re-use with inherent predictability and safety.
<snip>
Stateful Traits suggest that as long as the data is private _to the Trait_ then
we can safely ignore some of the complexity of state in Traits - it just isn't
exposed as the Trait declaration itself is a closure. Dependency on state in
the consumer could proxy to class/instance/value-type data via Protocol.
Yes, but this means that said data may be duplicated and need to be kept in
sync between traits and the main type. It also means that traits cannot be used
while extending an existing type to meet new protocol requirements outside a
module, as that may change the size of the type itself to be different than
what precompiled code expects.
If I understand you correctly (please elaborate if I don't :)) the data that a Trait owns would
never be visible to any consumer, other Trait(s), or any other instance where that same Trait has
been consumed. It wouldn't necessarily need to be stored against the consuming Type, only made
visible to that specific Trait "instance" for use by its methods. Trait data wouldn't be
shared with any other code, the consumer or even other "instances" of that Trait being
consumed elsewhere, so I think of it more as lexically scoped private variables - similar to
contextual data visible to a closure, yet no other code will be able to see or access them. It
wouldn't necessarily need to be stored with the consuming Type, but I don't know if that's even
feasible or desirable yet.
Exactly how Traits could be implemented under the hood for Swift - I'll do some
reading and walk through the source, but others would be better placed to
comment on the feasibility of this right now. I'm curious, so I'll see what I
can come up with on my own.
Cheers,
--
Niall Young
[email protected]
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
