8. End Sub 9.
E.g. so:
# module1.nim
type SomeClass* = object
m_Var1: int
m_Str1: string
m_For_Prop: int
proc newSomeClass*: SomeClass =
result.m_Var1 = 5400
result.m_Str1 = "A String from consrtuctor"
proc PrintMembes*(self: SomeClass) =
echo self.m_Var1
echo self.m_Str1
echo self.m_For_Prop
proc AProp*(self: SomeClass): int =
self.m_For_prop
proc `AProp=`*(self: var SomeClass, value: int) =
self.m_For_Prop = value
# module2.nim
import module1
var Aclass = newSomeClass()
Aclass.PrintMembes
Aclass.AProp = 555
proc `=destroy`(self: var SomeClass) = echo "destroying " & $self
Destructors work not very smoothly. At least with global variables.
Types (including object types) are infered in Nim. As newSomeClass is declared above as returning SomeClass, you don't need to declare the variable's type - compiler can determine it unambiguously. But you still can to state it explicitly, var Aclass: SomeClass = ..., compiler will check it. You can assign variable later, then its type is required at definition. I.e., this all is not related to OOP, just to variables.
Very concise still exhaustive Nim's manual explains well both topics.
Just write it like any other proc, although currently it is not possible for them to be automatically triggered when a variable gone out of scope:
type
SomeClass* = object
m_Var1: int
m_Str1: string
m_For_Prop: int
proc destroySomeClass*(sc: var SomeClass) =
sc.m_Var1 = 0
sc.m_Str1 = ""
Anywhere else I actively try to avoid it.
And for naive getter and setter, you can just make the fields public. They are useful only if input must be validated or update is not trivial (like for the times module).
For a library, when you need to build a heterogeneous collection of objects with types that can be user defined.
Why don't object variants work here, instead of OOP? I don't see the need to introduce method for this case.
The only thing OO provides is open recursion, which I haven't needed in most of the code I write.
Library users cannot change the kind discriminant of an object variant without forking the library.
For example in Arraymancer, if you have some neural network layers predefined from super simple (addition, matrix multiplication, mean, sum) to more complex (convolutions, softmax, ...). I can't hardcode the kind of layers as that would prevent users to define their own without forking the "LayerKind" enum.
Oh I see; I had assumed your container API was generic (in the sense of parametric polymorphism) but you have some kind of subtyping there.
I hope that when Nim 1.0 comes in 2037 that there's a different solution than the current method. Something more minimalistic, like Ada (>95) provides. I think those would address your use case.