-1

Here is the Protocols:

protocol WireFrameProtocol{
    // router for all normal cases
    // like showing login page
    
}

protocol InteractorProtocol{
    var wireFrame: WireFrameProtocol? { get set }
}

protocol HomeWireFrameProtocol: WireFrameProtocol{
    // home specific routers
}

protocol HomeInteractorProtocol: InteractorProtocol{
    var wireFrame: HomeWireFrameProtocol? { get set }
}

class Test: HomeInteractorProtocol{
    var wireFrame: HomeWireFrameProtocol?
}

extension Test: InteractorProtocol{
    
}

WireFrameProtocol will have all the routing functions. HomeWireFrameProtocol will extend and have some home relating routing only. The test class inherits from HomeInteractorProtocol, which has a var wireFrame: HomeWireFrameProtocol, again HomeWireFrameProtocol is extending WireFrameProtocol.

Is var wireFrame: HomeWireFrameProtocol also represent var wireFrame: WireFrameProtocol?

Phil Dukhov
  • 67,741
  • 15
  • 184
  • 220
Asis
  • 683
  • 3
  • 23
  • 2
    Simplify, simplify, simplify. This question is very hard to read because it contains so much code, remove any code that isn't relevant for the question. And a language thing that could also clarify the question, a struct or a class conforms (or implements) a protocol. Extending is when a class or protocol inherits from another class or protocol. – Joakim Danielson Jun 29 '20 at 05:45
  • @JoakimDanielson few base protocols, extend these protocols in other specific protocols and create class base by using Extended protocol. FOR TLDR; there is a gist you can build and try it yourself to create the issue and resolve it. – Asis Jun 29 '20 at 05:51
  • As for the actual question, if a protocol defines a `var x: String` you need to implement a property with that exact same signature and not something that is almost the same. Too bad you can't take some advice to help you improve your question. – Joakim Danielson Jun 29 '20 at 05:53
  • I don’t see what the question is. Do you imagine that the compiler is wrong? – matt Jun 29 '20 at 06:07
  • @JoakimDanielson I will try to make the question minimum soon. so that it will only focus in real problem. – Asis Jun 29 '20 at 06:15
  • @matt No I did not mean if the compiler is wrong. I have changed the question with a more simplified version I can come up with. – Asis Jun 29 '20 at 07:03

2 Answers2

1

Ok I realise it now, and fixed my own problem. What I did was

protocol HomeInteractorProtocol: InteractorProtocol{
    // do not create another variable to store HomeWireFrame
    // var wireFrame: HomeWireFrameProtocol? { get set }
}

The variable wireFrame: WireFrameProtocol can also hold the reference of HomeWireFrameProtocol.

so in Test class I updated:

class Test: HomeInteractorProtocol{
    // can use all features from the WireFrameProtocol
    var wireFrame: WireFrameProtocol?

    // also can use all the feature from HomeWireFrame
    // this is kind of what I want to achieve without creating two different variables in the protocols
    var homeWireFrame: HomeWireFrameProtocol? {
         return wireFrame as? HomeWireFrameProtocol
    }
}

extension Test: InteractorProtocol{
    
}
Asis
  • 683
  • 3
  • 23
0

If I understand your question correctly then you have just encountered a traditional Dimond Problem where it is ambiguous as to which parent class a particular feature is inherited from.

Your view and wireFrame both the variable declared in HomeViewPresenterProtocol and HomeViewInteractorOutputProtocol. So when you confirm these two protocols in HomeViewPresenter the Dimond problem arise. Compiler is confusing to this ambiguous parent.

The easiest solution is to change the variable name as you can't have the same variable or function signature.

Asis
  • 683
  • 3
  • 23
Tapas Pal
  • 7,073
  • 8
  • 39
  • 86