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

[Tino Heth via swift-evolution]

> While the \ syntax will only apply to key paths to begin with, we want to 
> look into unifying all unapplied member references under that syntax.

Glad to hear that — I hope the core team will keep the courage to break syntax 
from time to time if the change improves the consistency of Swift.
But like anyone else, I prefer breaking changes to happen rarely, and I think 
other parts of the language should be taken into account as well.

KVC is nice, but I would really like to see some sort of namespace for querying 
and working with "meta-properties":
— function references
— properties
— MemoryLayout
— functions (I'm thinking of stuff like introspection of parameters, and 
something like "apply" as a replacement for tuple splat)
— mirrors
— (most likely, I forgot some other possibilities)

There's no concrete vision for such a concept, but I'll just use ":" for 
illustration...
let appender: (Array, Int) -> Void = Array:methods:append
let someStaticFunction = MyType:classMethods:setGlobalInstance
let sizeProperty = Array:properties:size
let bytesNeeded = Double:memoryLayout.size
if theFunction:signature.parameters = [Int, Int] && 
theFunction:signature.returnType == T {
return theFunction:callWith(myPairOfInt)
}
let parent = Self:superclass
for type in UIViewController:allKnownSubclasses {…

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe Groff via swift-evolution]

> On Apr 12, 2017, at 7:48 AM, Andrey Volodin via swift-evolution 
>  wrote:
> 
> 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:
> 
> public class Foo {
> public var a: Int = 0
> }
> 
> public final class Property {
> public var `get`: (U) -> () -> V
> public var `set`: (U) -> (V) -> Void
> 
> public init(getter: @escaping (U) -> () -> V, setter: @escaping (U) -> 
> (V) -> Void) {
> self.get = getter
> self.set = setter
> }
> }
> 
> // Generated code
> public extension Foo {
> public static let a: Property = {
> return Property(getter: { instance -> (Void) -> Int in
> return { return instance.a} },
>   setter: { instance -> (Int) -> Void in
> return { value -> Void in 
> instance.a = value } })
> }()
> }
> 
> let foo = 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?

KeyPath is pretty much exactly your Property; however, keypaths are 
also intended to support equality as well as other reflective features down the 
line, so they need a bit more information under the hood than just an opaque 
closure. Our original proposal suggested exactly this syntax, but we rejected 
it because we felt like the unapplied member syntax looks too much like a 
concrete property/method reference, even in its existing form for methods. 
While the \ syntax will only apply to key paths to begin with, we want to look 
into unifying all unapplied member references under that syntax.

-Joe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brad Hilton via swift-evolution]

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{
> 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= {
> returnProperty(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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andrey Volodin via swift-evolution]

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:

public class Foo {
public var a: Int = 0
}

public final class Property {
public var `get`: (U) -> () -> V
public var `set`: (U) -> (V) -> Void

public init(getter: @escaping (U) -> () -> V, setter: @escaping (U) -> (V) 
-> Void) {
self.get = getter
self.set = setter
}
}

// Generated code
public extension Foo {
public static let a: Property = {
return Property(getter: { instance -> (Void) -> Int in
return { return instance.a} },
  setter: { instance -> (Int) -> Void in
return { value -> Void in 
instance.a = value } })
}()
}

let foo = 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution