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

[Myles Schultz]

> On Feb 15, 2016, at 8:04 PM, Wallacy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> In the last mail a mean, this:
> a#lazy.clear()
> b#observable.addObserver()
> 
> I forgot the name of the behavior. ;)

Maybe that is a bad prognosis for this feature. The more the discussion progresses, the complex it becomes and the worse the syntax becomes. 

Myles

> Syntax can be discussed in another thread anyway.
> 
> __
> 
> Just a question, there any plan to discuss some candidates as "default" behaviour on Swift 3 time-frame? Like 'lazy', 'observable', etc?
> 
> And some this "future work" like "Composing behaviors"?
> 
> I ask this because, knowing that we can use some of the functionality in time to propose improvements even before finalizing the version will help us suggest adjustments and reinforces the idea of a very simple initial proposal.
> 
> 
>> Em seg, 15 de fev de 2016 às 21:26, Drew Crawford via swift-evolution <swift-evolution at swift.org> escreveu:
>> I've been meaning to review this one.
>> 
>>> What is your evaluation of the proposal?
>> 
>> This is an excellent proposal.
>> 
>>> Is the problem being addressed significant enough to warrant a change to Swift?
>> 
>> Yes.  Actually, the "examples" within the proposal itself really only scratches the surface of the places I want to use this feature.
>> 
>> Swift's reflection system is pretty poor, supporting only read-only access.  If I was writing a library to parse the options to `swiftc` for example, an application might want to declare a structure like
>> 
>> struct Options: String {
>> 	let applicationExtension : Bool
>>         let assertConfig: Bool
>>         let embedBitcodeMarker: Bool
>>         let emitBitcode: Bool
>>        //etc
>> }
>> 
>> ...and use this application-provided structure as part of the API itself.  With clever use of Mirror, a library can reflect this structure, re-interpret the names under command-line-case-rules, and generate a parser that can read "-application-extension" "-assert-config" "embed-bitcode-marker" and so on.
>> 
>> However, while a library can understand this structure, it cannot set the values back on the structure defined by the application.  Thus the application is doomed to work with a parse result object that has poor type information (such as a stringly-typed result).  This basically negates the benefit of declaring a structure like this to begin with.
>> 
>> After this proposal, I can define a property behavior that relocates the variable storage to a stringly-typed underlying mechanism.  As a result, I can construct a full-duplex bridge between "stringly-typed" access patterns and "statically-typed" access patterns, allowing me to alternate between one and the other as necessary.  I can also get "writeable" reflection behavior.  
>> 
>> I think the benefits of such a scheme (particularly as an opt-in mechanism, so as not to impact performance in general) is pretty endless.  The API that I describe seems "obviously" the optimal API for practically any parse problem that terminates in a strongly typed structure (which is the case for most JSON, YAML, XML, CSV, CLI, and RPC-type application-layer problems), and under this proposal it becomes achievable.
>> 
>> One obvious extension I would like to see is "function behaviors" (a.k.a. decorators), but that is obviously a story for another proposal.  Still, I would be really interested in studying in that direction in future proposals.
>> 
>> As others have mentioned, composeability is also interesting, but may not be entirely necessary for an initial pass at the feature.  This seems like something that should be evaluated in the context of "so now we have two different libraries that each want their behavior on a property," which is a circumstance far removed from the present.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> As explained above, the proposal can bridge an important problem; namely allowing dynamic behavior in a static type system.  I think that this would allow clever library authors to design more Swift-like APIs.
>> 
>>> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 
>> I am familiar with function decorators in Python, which are a generalization of this scheme (they're composeable and they also work for functions).  I miss decorators terribly in Swift.  These are not quite as good, but they're a step.
>> 
>>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> I've tried to get to the meat of the proposal.
>> 
>> I'm deliberately avoiding the syntax bikeshed here–I'm much more interested in the behavior this proposal unlocks than the color of the paint.  Paint the damn thing any color you like, but the underlying idea here is a really important step towards more dynamic kinds of runtime behaviors.
>> 
>> Drew
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> 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/20160216/1ee8a5c0/attachment.html>