Mirror of forum.nim-lang.org

5413 :: How to privatize the proc of the inherited parent object？

• javinyang (orginal) [2019-10-28T06:37:40+01:00] view original

  In c++

  
  class Preant {
  public:
      void call() {
      
      }
  
  };
  
  class Child : public Preant {
  private:
      void call();
  };
  Run

  In nim

  
  type
    Preant* = ref object of RootObj
    
    proc call*(this: Preant) =
          echo "Call Preant"
  
  type
    Child* = ref object of Preant
    
    # Unable to privatize Preant call
    proc call(this: Child) =
          echo "Call Child"
  Run

  I don't know how to do it in nim?

---

• mratsim (orginal) [2019-10-28T10:14:53+01:00] view original

  Btw: you should use method here if you want dynamic dispatch based on the runtime type.

---

• javinyang (orginal) [2019-10-29T04:22:31+01:00] view original

  Not even with method

---

• cantanima (orginal) [2019-10-29T06:46:27+01:00] view original

  1. Before answering the question, I'd argue that this is one of many C++ defects you really ought to avoid. I'm not alone in this. If a class inherits behavior from its parent, it ought not attempt to undefine that parent's behavior. Unless you're building trivial software, you will break something sooner or later. If you don't believe me, pay special attention to the last sentence of the accepted answer on that page.
  2. I think the kludge below does something like what you want, but it really is a kludge (I am not a Nim expert). First, a module to define the types:

  type
    Preant* = ref object of RootObj
  
  proc call*(this: Preant) =
    echo "Call Preant"
  
  type
    Child* = ref object of Preant
  
  proc call*(this: Child) {.compileTime.} = discard
  Run

  Now a module that attempts to use them:

  import preant
  
  let c = new Child
  let p: Preant = c
  
  c.call() # does not compile if this is left uncommented
  p.call() # compiles and runs, calling p's call()
  
  Run

  Output with c.call() uncommented:

  
  $ nim c use_preant.nim
  Hint: used config file '.choosenim/toolchains/nim-1.0.2/config/nim.cfg' [Conf]
  Hint: system [Processing]
  Hint: widestrs [Processing]
  Hint: io [Processing]
  Hint: use_preant [Processing]
  Hint: preant [Processing]
  CC: stdlib_system.nim
  CC: preant.nim
  CC: use_preant.nim
  Hint:  [Link]
  Hint: operation successful (14420 lines compiled; 0.523 sec total; 15.992MiB peakmem; Debug Build) [SuccessX]
  $ ./use_preant
  Call Preant
  Run

  Output with c.call() commented:

  
  $ nim c use_preant.nim
  Hint: used config file '.choosenim/toolchains/nim-1.0.2/config/nim.cfg' [Conf]
  Hint: system [Processing]
  Hint: widestrs [Processing]
  Hint: io [Processing]
  Hint: use_preant [Processing]
  Hint: preant [Processing]
  use_preant.nim(6, 3) Error: request to generate code for .compileTime proc: call
  Run

  I'm sure someone better versed in Nim will come along with a more elegant answer, and maybe someone will berate me for berating C++, and that's OK; I'll learn. Until then, I maintain that you really shouldn't go down this road to start with.

---

• javinyang (orginal) [2019-10-29T08:19:52+01:00] view original

  The premise of not using this way is that the type is perfect design from the beginning , but not all type can be designed perfectly from the very beginning.

---