I want to use "complex objects" in NetLogo, that have several attributes. These are not agents, so they do not "act" from the perspective of the model.
A possible way would be to just use a list for these objects, where each index would be a specific attribute - so for example, if the object has the 3 attributes "price", "weight" and "name", then a list with 3 elements would store it in this order.
Using a turtle - specifically, a breed of turtles - would allow me to name these attributes. This might be useful in the future, as it makes the code way more readable - it is not clear that the second element of the list is weight, for example. However, a turtle suggests that it is an agent/actor.
Is it against conventions to use turtles for modeling non-agents, and I should go with lists? Or is there some third possibility I am not considering?
I tried creating lists in the aforementioned way, but it made way less clear. It was difficult to read and develop for me, so I believe that someone who did not even work on it before would be even more confused.
Edit for clarifications: the objects I want to use would be items, that agents "own". They would have several attributes, and could change ownership during a step of the program. Their attributes would matter for, inter alia, whether two agents want to exchange ownership of these objects, and how much they "pay" or "gain" for them. There would be many of these items, and different instances would get created at different parts of the runtime of the program.
I use separate breeds of turtles as non-agent objects all the time. For example, in our river trout model (https://ecomodel.humboldt.edu/instream-7-and-insalmo-7) the fish are one breed, their nests are another breed (and do nothing but keep track of where the nest is and how many eggs survive), another breed simply holds the variables of habitat cells that are polygons imported from GIS, and another breed (hidden so you don't even see them) holds variables of river reaches.
I don't see anything unconventional or otherwise wrong with your idea; to me it makes perfect sense. I certainly wouldn't recommend giving up all the advantages of NetLogo just because you need something that looks more like standard object-oriented programming.