[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Jan 25, 2016, at 8:15 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Jan 25, 2016, at 18:54 , Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>> 
>>> On Jan 25, 2016, at 6:40 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>> 
>>> Finally caught up. :-) I like this latest version better than the two previous versions, but I kind of think that if behaviors can't emulate "lazy", we've failed. Nothing has a stronger motivation than that at this point in time; there's lots of cool things we could use behaviors for, but you can still write all of them with a wrapper type.
>> 
>> Not sure what you mean. It can.
> 
> But you have this in your other message:
> 
>> For now, I'm saying initializer requirements are always "eager" (can't refer to self) and always inline-initialized.
> 
> Is it really just "can't refer to self" and not actually "eager"?

`lazy var`s still can't refer to self today AFAIK (I know we tried to fix that, but we still get plenty of radars saying it doesn't work…), so I don't think it would be a regression for a behavior implementation not to immediately be able to either. (And I'm not proposing we immediately replace our existing 'lazy' implementation immediately either.)

>>> - Someone else brought this up, but can I override behavior methods in a subclass with a new behavior? Can I invoke super's implementation of those behavior methods?
>>> 
>>> - Can I wrap a superclass property with a behavior? This version of the proposal doesn't have 'base', so I assume the answer is no, but that knocks out the other special-case language feature that was to be replaced by the general feature.
>> 
>> We're not done yet; this is just version 1. I'm subsetting composition out, since that's also an interesting discussion unto itself. You ultimately ought to be able to wrap a superclass property in new behaviors, but I don't see how you could replace a behavior without violating the superclass's encapsulation. Chaining to super behavior members also feels a bit overly intimate; do you have a use case in mind?
> 
> willSet or didSet wrapping a superclass setter is not at all uncommon, and the sort of things you wrap with didSet are usually things that want to know about reset() as well.

That's another interesting composition dilemma—if you wrap a property in observers in a subclass, then you'd probably want the base class's 'resettable' behavior to trigger the subclass's observers.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/338d4ef5/attachment.html>