If when assigning an object you don't want it to be copied, ref are a natural
fit. For example a resource like database connection or a network socket, when
you pass those around you don't want to suddenly create a new one, so use ref
for those. Note that you usually don't create those in a tigh
Yes "ref" and "new" aren't the only way to create memory dynamically. I written
my post too quickly.
> If you want your program to spawn objects during runtime you'll need ref
> objects.
Not really. For example, when you have a single value object and add() it to a
seq, it is copied -- similar as C++ vector does copy when you use
std::vector::push_back(). You can modify your value object then,
If you want your program to spawn objects during runtime you'll need ref
objects.
The inheritance way seems to be more easy for me. The case statement in that
type declaration looks like Chinese for me (just joking :)) Well, you showed 2
methods and stated the pros and cons of those 2 methods. Thats really helpful.
Now one can easily choose what they want from this. Great. Le
You seem to be attacking my each words carefully. But I do not want to take
this as an attack. I would like to take this as a help as you said. I think
there is no XY Problem in this case. Because you understood my real problem
properly from my words. Well, You are right. My previous experience
I just read your answers carefully and I will tests these solutions, my project
is much more complex than the example.
Thank you all for taking the time to write such insightful answers.
Here you go:
type
Shape = ref object of RootObj
Rect = ref object of Shape
width:float
height:float
ConvexP = ref object of Shape
vertices:seq[float]
type Drawing = object # Don't use ref object if there is no need, th
> But strict typing is killing us
I'll repeat what I have already tried to tell you several times, based on the
examples/questions you have posted previously.
I don't think 'strict typing' is what is killing you. It is your idea to do
things "the old way", like you did them in some other langua
> I want an object field to be able to handle two differents types with a clean
> syntax on the user side
Take a look at [Object
variants](https://nim-lang.org/docs/manual.html#types-object-variants) section
in the manual, maybe that is something you can use in your case.
> What is your suggestion ?
When you already use ref object, you may consider inheritance. Or you may use
sum types (union types) -- maybe bad if memory footprint of your objects
differs a lot.
Sounds like you want [dynamic
dispatch](https://nim-lang.org/docs/manual.html#multiminusmethods). Note that
`Rect | Convex` is not a concrete type, so you can't have `seq[Rect | Convex]`.
Are you sure ? A colon ? Not an equal sign(=) ?
I also want to know the answer. I have tried a lot. But strict typing is
killing us. Now, i can compile this code only if i use 2 distinct members in
Drawing.
` type RectOrConvex: Rect | Convex `
Run
Sorry for that basic topic but I want an object field to be able to handle two
differents types with a clean syntax on the user side. No problem if the code
behinds the scene is a hacky template or something, but the user should never
need to see that.
I written a simplified example.
16 matches
Mail list logo
