Protocol Conformance


(Muhammad Tahir Vali) #1

Hey all,

I wanted to know if theres a work around for a problem I am having

lets say I have a protocol

protocol *Graphable* : CustomStringConvertible, Sequence, Collection {
    var vertices : [AnyVertexable] { get set }
* var edges: [AnyEdge]? { get set }*
     ....
    ....
}

Then I have 2 classes that inherit from them

class *EZUndirectedGraph* : Graphable {
    var vertices : [AnyVertexable]
* var edges: [AnyEdge]? *
     .....
}

class *EZDirectedGraph* : Graphable {
    var vertices : [AnyVertexable]
* var edges: [AnyEdge]? *
* // *var edges : [AnyEdge]
    ....
}

Is there a way for me to make the "edges" variable in "*EZDirectedGraph*"
to NOT be an optional while still conforming to the same protocol? As one
may know, a condition for directed graphs requires there to be atleast 1
edge.

Advice or alternative workarounds would be nice with respect of what I am
trying to do here with Graph Theory.

My last 2 options were to either

1. Create separate protocols for the different types of graphs but there's
many types so I would be writing a lot of redundant code.

2. Leaving it how it is. Inserting an enum "TypeOfGraph" for the different
types of graphs and then computing its type with the help of the different
initializer methods.

···

--
Best Regards,

Muhammad T. Vali


(Karl) #2

I don’t think that works, but in your case it would not be safe anyway. The (Optional-typed) property “edges” is mutable in the “Graphable” protocol — that means that anybody could take an EZDirectedGraph (where the property is non-optional), cast it to a Graphable, and set its “edges” property to nil. Or some generic code might do that.

Personally, I would recommend removing the optional. If you’re trying to represent the difference between possibly-empty-edges/not-empty-edges, the optional isn’t actually going to give you that safety. After all, there’s nothing in the type-system which says that EZDirectedGraph’s array is not empty. You would need to document that and add assertions when mutating.

If you really wanted to make it rigorously safe, you could create a NonEmptyArray<T> struct which wraps an Array, intercepts mutation events and enforces that the underlying Array is never totally emptied. Then you would need to replace “edges” in Graphable with an associated type. That level of rigorous safety might not be required or even desired — on the other hand, it might help people to detect common bugs more easily. It all depends on your use-cases and your users.

- Karl

···

On 20. Jun 2017, at 01:38, Muhammad Tahir Vali via swift-users <swift-users@swift.org> wrote:

Hey all,

I wanted to know if theres a work around for a problem I am having

lets say I have a protocol

protocol Graphable : CustomStringConvertible, Sequence, Collection {
    var vertices : [AnyVertexable] { get set }
    var edges: [AnyEdge]? { get set }
     ....
    ....
}

Then I have 2 classes that inherit from them

class EZUndirectedGraph : Graphable {
    var vertices : [AnyVertexable]
    var edges: [AnyEdge]?
     .....
}

class EZDirectedGraph : Graphable {
    var vertices : [AnyVertexable]
    var edges: [AnyEdge]?
    // var edges : [AnyEdge]
    ....
}

Is there a way for me to make the "edges" variable in "EZDirectedGraph" to NOT be an optional while still conforming to the same protocol? As one may know, a condition for directed graphs requires there to be atleast 1 edge.

Advice or alternative workarounds would be nice with respect of what I am trying to do here with Graph Theory.

My last 2 options were to either

1. Create separate protocols for the different types of graphs but there's many types so I would be writing a lot of redundant code.

2. Leaving it how it is. Inserting an enum "TypeOfGraph" for the different types of graphs and then computing its type with the help of the different initializer methods.

--
Best Regards,

Muhammad T. Vali
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users