> One way to escape this bind is to supply the Worker value to the operation as a parameter
Thank you, Ser Eskimo! It's not exactly the level of terseness I was hoping for but it works well at the calling site and that's more than good enough!
I should explain what I am trying to achieve with this pattern, so that Apple may identify the use case and provide better support for it:
I am making a game using Swift 4, SpriteKit and GameplayKit. The "Worker" example above is actually a subclass of GKComponent, that I call a "CustomClosureComponent".
When I create a GKEntity, I add a CustomClosureComponent to it, and tell it which actions it should perform upon its private SKSpriteNode every time the component's update(deltaTime:) method is called per frame.
So my code was supposed to look somewhat like this:
let monster = GameEntity(name: "monster", components:
[VisualComponent(position: point),
AnimationComponent(frames: idleFrames),
CustomClosureComponent {
monstersPrivateSprite.doSomethingEveryFrame(like: this)
}
])
Now I guess I'll just have to make a minor addition:
let monster = GameEntity(name: "monster", components:
[VisualComponent(position: point),
AnimationComponent(frames: idleFrames),
CustomClosureComponent { component in // or leave it out and use $0, but this is clearer.
component.publicSprite.doSomethingEveryFrame(like: this)
}
])
And it works! Thanks!
As for improved syntax, do you think Swift could use a "local" or "calledScope" keyword, that refers to the scope of the called method, unlike "self" which means the scope of the caller? So that we could write:
let newWorker = Worker {
local.iVar += 1
}