Oops, I should have noted:
1) A getter doesn't require (or allow, IIRC?) parentheses, whereas a func call
does, even if it takes no arguments.
2) I was looking at the problem from the caller's end (i.e. client code), not
the callee's end, so the semantic requirements (such as getters not being able
to modify instance variables) aren't a consideration here.
On Jun 25, 2016, at 1:59 PM, William Squires <wsqui...@satx.rr.com> wrote:
> Let's take the CustomStringConvertible protocol, for example.
>
> You can use this to allow your class to "display" itself in a human-friendly
> format (for debugging, let's say), and you implement a function called
> description() -> String. But would it make a difference if you have a getter
> named description that has type String?
>
> i.e.
>
> class MyClass : CustomStringConvertible
> {
> var description: String
> {
> get
> {
> return "This is a MyClass instance"
> }
> }
> ...
> }
>
> vs.
>
> class MyClass : CustomStringConvertible
> {
> public func description() -> String
> {
> return "This is a MyClass instance"
> }
> ...
> }
>
> If there is, what are the ramifications? Is there a way to make a Swift
> protocol such that any class, struct, or enum that implements it can provide
> either a getter or a func in order to satisfy it, without having to specify
> both the getter and the func in the protocol? Since swift protocols don't
> have optional implementation, unlike ObjC protocols, this would force any
> implementer to provide both the getter and a func, right? Will something like
> this be part of Swift 3?
>
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
