[swift-evolution] Unify the way properties and methods work to make key-value coding more natural

Brad Hilton brad.hilton.nw at gmail.com
Wed Apr 12 14:28:50 CDT 2017


I like the .get syntax better than \
I’d be okay with the slightly more verbose .getter
Foo.a could return a tuple: (getter: (Foo) -> () -> A, setter: (Foo) -> (A) -> ())

> Recently I’ve seen some upcoming changes for #keyPath, but the whole things look a bit messy to me. Today I came up with a simple idea of code generation, but I thought maybe it would be nice to make this a part of the language?
> 
> Look at this code:
> 
> publicclassFoo {
> publicvara:Int=0
> }
> 
> publicfinalclassProperty<U, V>{
> publicvar`get`: (U) ->() ->V
> publicvar`set`: (U) ->(V) ->Void
> 
> publicinit(getter:@escaping(U) ->() ->V, setter:@escaping(U) ->(V) ->Void) {
> self.get = getter
> self.set = setter
> }
> }
> 
> // Generated code
> publicextensionFoo{
> publicstaticleta:Property<Foo,Int>= {
> returnProperty<Foo,Int>(getter: { instance ->(Void) ->Intin
> return{returninstance.a} },
> setter: { instance ->(Int) ->Voidin
> return{ value ->Voidininstance.a = value } })
> }()
> }
> 
> letfoo = Foo()
> foo.a =5
> 
> let_a = Foo.a.get(foo)()
> print(_a)
> 
> Foo.a.set(foo)(10)
> print(foo.a)
> 
> 
> The idea is to make properties work the same way the methods work right now. That will allow things like tweening properties in the game engine, by simply passing the property to some sort of ActionManager.
> 
> Of course, this can be achieved by code-generator, but I bet this will be very ineffecient in terms of performance.
> 
> The only draw back here from top of my head: It will be impossible to have instance- and static- variables with the same name.
> 
> What do you think about this?_______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 


More information about the swift-evolution mailing list