Well, yes and no. A decorator receives a method and returns a new method, and it's up to implementation what will happen in the new method - it can perform some operations before calling the original method, or doing something after the original method is called, or not calling the original method at all. But a decorator must be applied to the function in compile time, so changing the behavior of functions from some library we don't have source (like UIView, in your example) wouldn't be possible.
At least according to my original proposal. The proposal can be changed, but we need to invent some new syntax for such decorators. Alex On May 16, 2016 at 16:25:08, Erica Sadun ([email protected]) wrote: On May 8, 2016, at 10:33 AM, Karl Wagner via swift-evolution <[email protected]> wrote: On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution <[email protected]> wrote: Hi swift-evolution, I want to apologize in advance for my clumsy English. It's (obviously) not my first language. Recent discussion about property behaviours reminded me of function decorators in Python. I think decorators can nicely fit in Swift, too. First, a bit of explanation for the uninitiated. Decorator is a function that transform other function - it receives some function and returns a function of the same signature. Lets make some dead simple decorator: In Objective-C, you can add a category that will entirely replace an existing method. Could using decorators allow us to add behaviors to methods to extend their behavior without overwriting those methods? Here is an example of what I'm thinking. extension UIView { decorate func somethingElse(...) { // performs existing behavior of somethingElse ... adds new behavior ... } } Context: I was asking about whether this kind of "extend rather than replace or subclass" behavior were possible in Swift, and was told that "decorators" might be the right technology to implement it. Thanks in advance for any insight. -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
