on Tue Nov 15 2016, Shawn Erickson <[email protected]> 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). If there are truly programming problems that don't have a clean solution without introducing optional requirements, I'd really like to see them. Speaking for myself: I think “probe-a-type” programming is in general a bad idea, and I'm opposed to adding features that encourage it. It's almost always better to design entry points into supertypes (protocols, or base classes if you must ;->) with default implementations that can be overridden to do the work you need based on the characteristics of a subtype, rather than trying to make decisions in the caller based on the shape of the type. When you *do* need probing, it's a good idea to make the set of possible subtypes a closed set, so the compiler can ensure you handle all cases—i.e., use an enum. > On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution < > [email protected]> wrote: > >> >> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution < >> [email protected]> wrote: >> >> >> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution < >> [email protected]> wrote: >> >> >> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution < >> [email protected]> 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 >> [email protected] >> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
