> On Apr 1, 2016, at 5:37 PM, Brent Royal-Gordon via swift-evolution
> wrote:
>
>> Protocol requirements with default (no-op) implementations already satisfy
>> that design goal, no?
>
> Kind of. If I may steelman* optional members for a moment...
>
> In cases where a default implementation
> On Apr 3, 2016, at 10:21 PM, Thorsten Seitz via swift-evolution
> wrote:
>
> As the problem seems to be to eliminate having to write the extension with
> all its duplication, I'd prefer a more general solution instead of
> introducing the notion of an "optional" function: just make it possi
> I'd prefer a more general solution instead of introducing the notion of an
> "optional" function: just make it possible to write default implementations
> inline in a protocol definition.
This would work, too. I guess there's no need for an “optional” keyword if the
implementation is right t
As the problem seems to be to eliminate having to write the extension with all
its duplication, I'd prefer a more general solution instead of introducing the
notion of an "optional" function: just make it possible to write default
implementations inline in a protocol definition.
Documenting th
I understand the concern.
To me, the answer is clearly yes. The language cannot be considered in
isolation from its use cases; imagine UIKit written in Swift.
You want the developers to be able to quickly understand which table view
delegate methods they need to implement, and what the contract
For readability and specifically in this case, I think it does make sense
IMHO.
On Sunday, April 3, 2016, Chris Lattner wrote:
>
> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov > wrote:
>
> Protocol requirements with default (no-op) implementations already satisfy
> that design goal, no?
>
>
>
> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov wrote:
>
>> Protocol requirements with default (no-op) implementations already satisfy
>> that design goal, no?
>
> Chris, as we've discussed in a thread that I think got forked from this one:
>
> Yes, they do technically, but it would be nice t
> Protocol requirements with default (no-op) implementations already satisfy
> that design goal, no?
Chris, as we've discussed in a thread that I think got forked from this one:
Yes, they do technically, but it would be nice to both:
1) make it an obvious documented part of the signature, possi
>> I've actually had multiple cases in Objective-C code where this feature
>> (some object behaving differently depending on wether or not a delegate
>> method has been implemented) has prevented me from implementing features the
>> easy and obvious way. In those cases I resorted to implementing
> I do not understand why an optional method should require a default value.
> That’s not how optional methods work in Objective-C where the caller will ask
> whether the method is implemented and calls it or does something else. With a
> default value it would be much more difficult to do somet
> Some ideas I was thinking about for optional protocol functions was you’d
> declare it like this:
>
> protocol UIGestureRecognizerDelegate {
> optional func gestureRecognizerShouldBegin(gestureRecognizer:
> UIGestureRecognizer) -> Bool = true
> }
>
> If you put “optional” there, the compiler
> On Apr 1, 2016, at 7:37 PM, Brent Royal-Gordon via swift-evolution
> wrote:
>
>> Protocol requirements with default (no-op) implementations already satisfy
>> that design goal, no?
>
> Kind of. If I may steelman* optional members for a moment…
I’d actually go a bit further: for at least *s
Sent from my iPad
> On Apr 2, 2016, at 7:04 AM, Lukas Stabe via swift-evolution
> wrote:
>
> All use-cases I had for optional methods in protocols in Objective-C are
> covered nicely by providing a default implementation in a protocol extension,
> so I don't think optional protocol methods
All use-cases I had for optional methods in protocols in Objective-C are
covered nicely by providing a default implementation in a protocol extension,
so I don't think optional protocol methods should be a thing in pure Swift.
> I do not understand why an optional method should require a default
Very good points Dietmar, but there is one more bit about default
implementations in extensions that makes it worse to use than the old
Objective-C model... the complex dispatch rules that can make the executed
method type dependent and not instance dependent. We really need dynamic
dispatch th
That’s an interesting idea. Although I still do not like the fact that the
Swift model forces me to split up the implementation between the delegating
type and the delegate whereas the ObjC model allows me to keep the default and
non-default implementation in a single place, namely the type.
Th
>
>
> class UITableView {
> ...
> private func addRow(at indexPath: NSIndexPath) {
> ...
> cell.size.height = delegate?.tableView(self,
> heightForRowAtIndexPath: indexPath) ?? rowHeight
>
-1
I hope that default implementations living in the protocol will address
this. I would even prefer to move in 'the other direction' and have
optional methods on protocols come into swift as default implementations.
TJ
On Sat, Apr 2, 2016 at 6:07 AM, Brent Royal-Gordon via swift-evolution <
swift
> Protocol requirements with default (no-op) implementations already satisfy
> that design goal, no?
Kind of. If I may steelman* optional members for a moment...
In cases where a default implementation would do, the default implementation
will usually also be the behavior you want for a nil ins
Good point. That would obviously restrict the choice for naming the methods in
such a protocol, but since we are talking about new protocols that would not be
an impediment. It might result in non-optimal method names, of course.
-Thorsten
> Am 31.03.2016 um 18:37 schrieb Rob Mayoff via swift-
>> None taken. However, most of the delegate concept of UIKit relies heavily on
>> this "nonsensical" requirement. It is impossible for someone to implement a
>> control in swift which is "in the spirit" of UIKit, meaning the control has
>> a delegate, with several methods that share the same na
> On 31 mars 2016, at 22:01, Chris Lattner via swift-evolution
> wrote:
>
> Protocol requirements with default (no-op) implementations already satisfy
> that design goal, no?
They do, but that is not clear for everyone. And after protocol extensions
appeared with 2.0, it took a little while
> On Mar 31, 2016, at 11:49 AM, Yuval Tal via swift-evolution
> wrote:
>
> None taken. However, most of the delegate concept of UIKit relies heavily on
> this "nonsensical" requirement. It is impossible for someone to implement a
> control in swift which is "in the spirit" of UIKit, meaning t
> On Mar 31, 2016, at 5:51 PM, David Waite via swift-evolution
> wrote:
>
> +1
>
> We need to support optional methods in @objc protocols because it is required
> for interoperability. However, there are in my experience only reasons for an
> optional protocol method:
>
> - There is a very
+1
We need to support optional methods in @objc protocols because it is required
for interoperability. However, there are in my experience only reasons for an
optional protocol method:
- There is a very common default behavior for a delegate (such as return
immediately with a value of 0/nil/fa
I think it's a bad idea because current model (with no optional methods)
encourages decomposing protocols into smaller ones, thus discouraging partial
functions and making our code safer and more predictable.
In my opinion, right now, if you really need an optional protocol method,
consider add
To be fair, the "spirit of UIKit" that you mention comes from a time and
language that encouraged OO and OO alone. Optional methods are, more often
than not, backed by gigantic bit fields that keep track of whether or not the
delegate actually conforms to the entirety of a protocol, which opens
This shouldn't be an issue in practice, though, since any UIKit control
subclass has to inherit from NSObject anyways, which means they can always
conform to any @objc protocol.
The main utility of removing the @objc requirement for optional protocol
requirements would to allow their use in Swi
> Caveat: this is going to be strongly-worded; sorry in advance. I think
> (no offense intended) it's a terrible idea. The whole notion of an
> “optional requirement” is nonsensical to begin with, and the use of
> optional protocol requirements encourages a style of programming that
> lifts the r
None taken. However, most of the delegate concept of UIKit relies heavily
on this "nonsensical" requirement. It is impossible for someone to
implement a control in swift which is "in the spirit" of UIKit, meaning the
control has a delegate, with several methods that share the same name with
differe
on Wed Mar 30 2016, Yuval Tal wrote:
> Hi,
>
> I find that optional protocol methods to be very useful. However,
> there is a caveat -- it needs to be mapped to @objc. This puts a set
> of limitations, such as: structures cannot be used as parameters as it
> does not map to objective-c. What do
On Thu, Mar 31, 2016 at 10:56 AM, Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:
>
> protocol UIGestureRecognizerDelegate {
> var gestureRecognizerShouldBegin: ((gestureRecognizer:
> UIGestureRecognizer) -> Bool)? { get }
> }
>
UIGestureRecognizerDelegate has five meth
> Am 31.03.2016 um 17:18 schrieb Sean Heber :
>
> Some ideas I was thinking about for optional protocol functions was you’d
> declare it like this:
>
> protocol UIGestureRecognizerDelegate {
> optional func gestureRecognizerShouldBegin(gestureRecognizer:
> UIGestureRecognizer) -> Bool = true
>
Some ideas I was thinking about for optional protocol functions was you’d
declare it like this:
protocol UIGestureRecognizerDelegate {
optional func gestureRecognizerShouldBegin(gestureRecognizer:
UIGestureRecognizer) -> Bool = true
}
If you put “optional” there, the compiler would auto-gener
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I'm missing those optional methods too, but protocol extensions sound like a
better solution for this.
(For those suggesting a separate protocol, consider UITableView. How many
protocols would it take to model all the optional delegate methods as separate
protocols? Certainly more than 10, perh
Hello,
I'm aware of all the protocol/extension or multiple protocol options. I
think that for the sake of code readability and the ability to easily
create components, it is extremely useful. For example, if I want to create
a class that has a delegate, it is extremely useful for the caller to
eas
Another alternative is to add a protocol extension with
blank/harmless/default methods for things that are optional and always call
'em.
On Wed, Mar 30, 2016 at 7:18 AM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:
> I’m not sure, why not just define an additional protocol wit
I’m not sure, why not just define an additional protocol with the optional
method(s) you’d like to add? The whole point of protocols is to guarantee
access to some baseline capability, so I’m not sure that optional capabilities
are well covered except by adding new protocols that extend each oth
Hi,
I find that optional protocol methods to be very useful. However, there is
a caveat -- it needs to be mapped to @objc. This puts a set of limitations,
such as: structures cannot be used as parameters as it does not map to
objective-c. What do you think about removing the requirement of using
@
40 matches
Mail list logo
