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

[Wallacy]

In the last mail a mean, this:
a*#lazy.*clear()
b*#observable.*addObserver()

I forgot the name of the behavior. ;)
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/d5b0ea08/attachment-0001.html>