I have a rather basic question about patching in vl. I think my problem has something to do with the whole immutable vs. mutable data discussion, which seems somehow blurry to me in vl. So here’s my problem:
I have an object (let’s say a canvas) which holds other object (i.e. ‘tiles’), which I want to drag accross the renderer. I understand that if I want to keep the tile’s position when done dragging, I would have to save it in a pad and feed it back to the drag operation. But what if that upper pad needs to be fed something from the top?
Part of the problem is probably that I don’t really know how to describe my problem. There still seem to be very basic concepts of vl that I have not yet understood.
If someone would like to enlighten me, she would be very welcome! :) movetest.zip (9.6 KB)
You’d need to write back your altered tiles back into you Canvas Datatype’s instance (pad), otherwise you’ll keep on splitting the Canvas element in its original state (with the Tile in place in the Origin).
It appears to snap back as you’re just overwriting the Position of the tile every frame.
It would be easier to patch and read if you would store the Tiles outside of the Canvas Datatype in a pad of your patch, it would need less setup … but your ultimate goal is probably to extend the Canvas datatype, which is why you need it like this?
there are obviously different ways you can do this. depending on your bigger picture…
first: your alternative approach works because there you create a single tile that you store in the “tile” pad and always write it back into that pad after you moved it. that is the way to do it. immutable style. and as a general rule for starters: simply forget about mutable.
it seems from your example that you’ll typically have one Canvas, which will hold many Tiles. as long as you have only one instance of something, don’t worry about making it a record, as you did with the Canvas. so i assumed that you’ll have one canvas, and not a dynamic amount of canvases, thats why i made the canvas patch a simple process:
3): inside, the canvas manages a spread of tiles, hence the “Tiles” pad: we have all the tiles there, sometimes we add a tile (if Add Tile), sometimes we move the tiles (if Move), but in the end, whatever we did, we write them all back to the Tiles pad:
as you can see, for a start there is also no need to use different operations. everything can be done on update.
the tile is an object of which you want to manage a dynamic amout at runtime, that is why you made it a Record. i didn’ t change that one.
hope that clarifies things a bit. let us know if something needs more explanation…
thanks a lot for the thorough clarification. As I assumed there was something inherently wrong with my approach. Seems I haven’t quite grasped the differences and usecases of records, processes, classes, operations… (btw some more pictures and examples in the gray book might help). Guess I will have to get back to you sometime until I really understand what I am doing. ;)
I will try to incorporate your concept into the bigger picture (bc as readme rightfully assumed, the actual goal is a little more complex).
Thanks! You’ll hear back from me (sooner or later) :)
v
