Note you can also use a protocol of optional methods to do the same things as the var... I for now haven't done it that way.
On Tue, Nov 15, 2016 at 7:46 AM Shawn Erickson <shaw...@gmail.com> wrote: > This has been discussed somewhat heavily in the past and nothing yet has > really moved forward on it. I do think a good way of doing something like > this would be helpful. I have resulted to defining an interface with an > extension that provides empty defaults and for each function a match bool > var exists to imply if it exists or not. The code accepting a delegate can > probe these bool vars to configure itself to efficiently operate based on > knowledge about what the delegate expects (some missing from most proposed > solutions other then @objc optional). > On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > > On 15 Nov 2016, at 12:22, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote: > > > On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution < > swift-evolution@swift.org> wrote: > > One major example is the NS/UITableViewDataSource or Delegate - there are > many many methods that you don't need to implement, hence are optional. > > But I think that this was partially solved by default implementation of > protocol methods, which pretty much does what you want... > > > I just realized I only responded to someone else, and not the whole list. > It does, but it forces me to make the return value of the protocol method > optional, so that the default implementation can return nil. > > In the end, I guess that's not so bad, since I'm not happy with the entire > approach, but it'll do for now. > > > What's different about having the method return nil vs being optional? > You're attempting to call it either way, and presumably need some means of > handling the return value, except in Swift it's all nice and explicit and > easy to put in a conditional like: > > if let result = myObject.someOptionalMethod() { /* Do some stuff */ } > print(myObject.someOptionalStringMethod() ?? "") > > And so-on. If you need a method to be both optional, and return a nilable > result then you can use a double optional like so: > > if let result = myObject.someDoubleOptionalMethod() { // Method was > implemented > if let value = result { // Method returned a value > /* Do some stuff */ > } > } > > > By defining the methods as returning an Optional and throwing in default > implementations you can specify fewer, bigger protocols and make clear what > the requirements really are, though personally given the choice I'd prefer > a dozen smaller protocols that are absolutely explicit in what they do. > > But yeah, I think the tools you need are all there already; maybe there's > an argument to be made for allowing default return values on protocol > methods, to reduce the boiler-plate? > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > I think there is a difference between: > > - A method which returns an optional result, and > - An optional method which, if present, always returns a result > > Perhaps not so much of a difference at the usage site (it’s just a > question of placing a ? for optional chaining), but semantically and when > conforming to the protocol, they mean different things. > > - Karl > > _______________________________________________ > 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