+1 to what Krux02 said. If you use Nim like that you don't gain very much over
Python. It will not be faster (as Nim and Python both need the work to be done
at runtime) and you won't avoid errors and lose easier reasoning and
refactoring possibilities because the compiler can't check the types
Ok, I get the problem here. At first I thought you would need an interface
object to interact with languages like Python, where you do not know the
fields. But you what you actually want is to treat Nim like as if it is Python,
and all I can tell you that is a bad idea, and don't do that. You sh
@flyx I guess it's not NEEDED because I can just store it in a table but after
using Python year after year it just seems like something natural.
The "solution" based on posts above is:
import tables
template `.?`*[T](a: T, f: untyped): untyped =
a[astToStr(f)]
This is not possible by design.
type
test* = object
Here, you declare an object that has no fields.
var t = test()
Here, you instantiate this object. `t` has the type `test`.
var t.name = "kek"
The compiler now looks at `t`'s type an
> So soemthing like Python's setattr() doesn't exist then?
I think when you want support for dynamic runtime attributes, you have to
prepare for it in a compiled language. For example you can add a field of type
seq or table to your object and a proc for adding data to this field. Of course
in
So soemthing like Python's setattr() doesn't exist then?
Afaik it is not. You could use a JSON Object for example or a Table and use
"experimental" pragma for dot overloading (in devel) or better using your own
operator like `.?` (which was already be planned to be as being part of the
compiler to allow: `foo.?bar` being equal to `foo[bar]` afair :)
Is this possible in nim?
An example of what I mean:
type
test* = object
var t = test()
var t.name = "kek" #This would fail to compile
