[swift-evolution] Properties on Default Protocol Implementations

[Trent Nadeau]

Syntactically, would PwS be special like class-only protocols are now or
would it be automatic by having stored property declarations within the
protocol?

On Mon, Jan 11, 2016 at 6:36 PM, Wallacy via swift-evolution <
swift-evolution at swift.org> wrote:

> FWIW:
>
> I quick look of my code base (in ObjC), i found 39 code points with I use
> ObjC associated objects, one of them is a crazy database manager (for
> postgres) with automatic look for the database, search the tables, search
> for the program to find classes with the same name, and automatic add a
> observer for all rows properties that match (surprisingly works).
>
> Others codes are more simpler, but my point with this proposal, despite
> all technical issues, is avoid some "to much creative" solutions to model
> the code, one in particular I am looking now (in swift), has 8 core data
> properties, and 8 transient and irrelevante properties just to maintain the
> everything sane (like avplayer Periodic Time Observer), and all 8 has
> default implementation using extensions, will be good declare some of the
> storage properties in a protocol and make each "behavior" (like monitoring
> the avplayer) a protocol to be reused.
>
> And think about the PwS noted by Chris, yes, maybe can be confusing add
> another "kind" of protocols, but like the Self requirement, generally, if
> well implemented, its just a matter of time (not so much) to people
> understand and drive a good protocol-oriented-programing code.
>
> Em seg, 11 de jan de 2016 às 16:35, Douglas Gregor <dgregor at apple.com>
> escreveu:
>
>>
>> > On Jan 11, 2016, at 10:27 AM, Chris Lattner <clattner at apple.com> wrote:
>> >
>> > On Jan 10, 2016, at 8:34 PM, Douglas Gregor via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >> 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.
>> >>
>> >> 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.
>> >
>> > Hi Doug,
>> >
>> > Have you considered this similar-but-different approach?
>>
>> Not this particular shade, but I understand your motivation.
>>
>> >
>> > - 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.
>>
>> This isn’t a different from my proposal in that regard ;)
>>
>> > 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.
>>
>> … this is the real benefit, and I agree. The overhead of associated
>> objects should require one to explicitly opt-in.
>>
>> > The primary downside of this approach is that it introduces yet another
>> weird protocol variant with limitations and behaviors, making the model
>> more complicated.
>>
>>
>> I think these semantics are reasonable, and the limitation is the same as
>> what I proposed: it’s hard to describe why the limitations are what they
>> are without a deep-dive into the implementation model.
>>
>>         - Doug
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160111/aaef586d/attachment.html>