I believe you’re referring to this
https://gist.github.com/erica/eb32feb22ba99629285a
<https://gist.github.com/erica/eb32feb22ba99629285a> currently being developed.
I was initially limiting this proposal to initializers, specifically overriding
them verses immediately following them. This is an important distinction
because it would require required properties, verses the initializers still
taking care of this. This doesn’t make it in opposition to method cascading, it
might possibly be a nice addition. It also appears like self is not maintained
(in that method cascading proposal anyhow), self is just not required unless
variables names overlap. Below is my exercise in keeping self.
Perhaps this alternative would work:
class Foo {
var name:String
init (name:String) {
self.name = name
}
}
class Fee {
var name:String = "Fee-fi"
static func createFoo (name:String) -> Foo {
let foo = Foo {
foo.name = self.name + "-" + name
}
return foo;
}
}
let name = "fo-fum"
let other = Fee.createFoo(name);
print(other.name) // "Fee-fi-fo-fum"
let another = Foo {
// name = self.name // Ambiguous, self isn't defined.
// self.name = name // Simplist, but isn't clear within scopes that contain
self (like class functions) It would require a common javascript work around
for this, saving a `that = this;` before the closure.
another.name = name // Clear, another is only required when names overlap
in scope.
// print((self == nil)) // true
}
This has restrictions. An initializer can’t be used directly within a return
for example:
class Fee {
var name:String = "Fee-fi"
static func createFoo (name:String) -> Foo {
return Foo {
return.name = self.name + "-" + name
}
}
}
That is admittedly awkward, bad form, but not technically wrong.
Unless there is a better alternative, keeping self the same inside the closure
as outside seems difficult to do, but not impossible.
-Weston
> On Jan 3, 2016, at 7:39 AM, Tino Heth <[email protected]> wrote:
>
> Something similar has been discussed ("method cascading"), and I hope the
> feature will be considered for Swift 4(?).
> It is a little bit different, though:
> "self" would not change its meaning (which imho is a plus), and the syntax is
> different.
>
> Tino
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
