[swift-evolution] two protocols with the same method name

[Wallacy]

Storage properties on protocol or in extension plus something when call
maybe a solution:

       protocol Marriageable {
               var foo:Int = 0; // actual a var.
                var ring: String? // actual a var.
        }
        protocol CallReceivable {
                var ring: String? // actual a var.
        }

        struct Person: Marriageable, CallReceivable { }

OR
        protocol Marriageable {
                var ring: String? { get set }
        }
        protocol CallReceivable {
                var ring: String? { get set }
        }

        struct Person { }

       extension Person: Marriageable{
         var ring: String?
       }

     extension Person: CallReceivable{
         var ring: String?
       }

So:

var person = Person()
person.foo = 1 // ok

person.ring = getRingtone() // error, ring is ambiguous
(person as CallReceivable).ring = getRingtone()  // ok
OR
person.CallReceivable.ring = getRingtone()  // ok | CallReceivable is a
know person protocol, so can get a implicity dot notation,
like .dynamicType.staticMethod();

Anyway, it's not an easy problem to solve.

Em sáb, 9 de jan de 2016 às 01:09, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> escreveu:

> > I don’t really get what you are driving at.
>
> The point is that, although `A` and `B` both require properties with the
> same name, they expect different semantics from that property. Let's maybe
> give these more concrete names so you can understand the idea:
>
>         protocol Marriageable {
>                 var ring: String? { get set }   // File name of image of
> this person's wedding ring.
>         }
>         protocol CallReceivable {
>                 var ring: String? { get set }   // File name of ringtone
> to be used for this person.
>         }
>
>         struct Person: Marriageable, CallReceivable {
>                 var ring: String?
>         }
>
> Of course a person is marriageable and can this have "a ring", and of
> course you can also receive a call from them and they can thus have "a
> ring". But in reality, the "ring" that satisfies one of these things will
> not work for the other. If your best friend gets married and you add an
> image of the ring, then the next time your friend calls you, the phone
> ringing screen will try to play a JPEG as an MP3.
>
> The "ring" example is, of course, slightly contrived, but I'm sure you can
> imagine a similar problem with real names, where you end up using the same
> term for two different and incompatible things.
>
> What the OP is basically asking is, when Swift sees the same type
> conforming to Marriageable and CallReceivable, should it optimistically
> assume that the `ring` properties they both require are compatible and
> allow the code to pass through without comment? Or should it
> pessimistically assume that the `ring` properties are incompatible and emit
> a warning or error about them?
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160109/9a8bef02/attachment.html>