[swift-evolution] [Review] SE-0030 Property Behaviors

[Myles La Verne Schultz]

You’re right, it may be too ambiguous, but you should know what behavior one of your properties has.  Ideally you know what is lazy.  When you forget, you can use Quicklook or look up the property declaration manually.  As far as setting a property to nil, that only makes sense for optional types.  Setting a non-optional Int to nil is an error--you can’t do it.  

var firstInt: Int = nil            // error, not an optional, regardless of behavior
var secondInt: Int? = nil    // ok

Thus, .clear() isn’t even applicable to the first case.  Even with the lazy case, setting the behavior to nil but the actual property to…0?  That doesn’t make sense either.

In regard to having multiple behaviors, the behaviors should be accessible like any other protocol conformance and automatically be made part of the properties possible function list.  You should not need to reference the behavior behavior because that should be understood just like the property being a var or a let should be understood.  So if a property is defined as being lazy, then the property automatically acquires all of the functions associated with lazy, if it has another behavior, it acquires those functions too.  Then .clear() or .doSomethingElse() become

foo.doSomething() or foo.doSomethingElse()

To me this makes more sense, but I guess it is just me.  If anyone else feels the way I do, I would appreciate their input or backing.  Perhaps having someone else explain it in their words would help?  I don’t know.  At any rate, it was just an idea.  I’m just trying to provide the syntax/thought process that feels more Swift.

Myles

> On Feb 13, 2016, at 8:00 AM, Jean-Daniel Dupas <mailing at xenonium.com> wrote:
> 
> This kind of shortcut may be ambiguous. How do you handle the case where both the underlying type and the property declare the same method ?
> 
> How do you handle the case where a property has more than one behavior ?
> 
> If the underlying property is not an Optional, being able to set it to nil is confusing, and if it is Optional, how would you now that setting it to nil should clear the lazy behavior and not affect the value nil to the underlying property.
> 
>> Le 13 févr. 2016 à 01:46, Myles La Verne Schultz via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> My apologies, I did not intend to be picky.  That case involving the use of .clear() just seemed like the most obvious.  My overall point was that if one has to reference the behavior every time the property is used, that becomes cumbersome and not really any better than what we have now.  So being able to apply property behaviors without have to
>> 
>> foo.[behavior].somethingHere()
>> foo.[behavior].instance = 1
>> etc. (pardon if I made any mistakes above, I was typing that from what I remembered from the proposal)
>> 
>> when we need to use them, would be more ideal.  In other words,
>> 
>> foo = 1
>> foo = nil
>> foo.doSomething()
>> etc.
>> 
>> I really like the idea of property behaviors, I just don’t like the syntax for how they are invoked.  That’s what I meant.  I really didn’t mean to mince words or be picky.  It was just a suggestion to help simplify the syntax if possible.
>> 
>> Myles
>> 
>> 
>>> On Feb 12, 2016, at 6:22 PM, David Hart <david at hartbit.com> wrote:
>>> 
>>> 
>>> 
>>>> On 12 Feb 2016, at 03:32, Myles Schultz via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Having to use dot syntax every time doesn't feel right. When it comes to the having to use .clear(), that really doesn't feel right. Setting value to nil seemed so much cleaner and simpler. 
>>> 
>>> 1) behaviors exist for implementing more than lazy, so making an argument about the calling syntax for 'clear' seems a bit too not picky for me.
>>> 
>>> 2) In the case of lazy, the property's type is often not optional. So setting the value to nil is a non-sensical from a type-checker point of view.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>