Ho ho,
Ive just read through again, and yes I think I do see your point.
Whilst it would be possible for you to implement a system to keep count of the refferance count. This would be a duplication of processing use as BMax has already done this internaly.
I see the code Dream posted, and I think I remember reading it as well, I think it got attacked by skid (I think this was the same one, there was a code post, and a thread here as well ). Because when all said and done its "Hack"
However. This is not like when you could change the spectrum font with a Poke. Everyone knew about it, everyone used it, and It would have gone wrong if there realesd a Spectrum version with a different address sytem for the font. Which is where it differs here. Its a valid hack, any code you produce with it will still run even when or if it is changed internaly. (Im not saying it will work if you recompile it, Im just saying and code alredy produced will work).
Now if BRL do change this system, what are they going to change it to? It can only change really in two ways, first the offset from the object could change. (Well youre going to store the ofset as a const anyway, so thats no problem). Or second, this are going to store the information consecutivly for all objects. (But in this case the still have to keep a pointer to point from the object to the number of instances (Or vise versa), and thats easyerky Hackable.
Ultimatly I agree with you, if the information is there inside the engine, and it really would only take a "Object.Refcount", I dont see why BRL dont just add it in. Come on half the command we use are undocumented already.
Ive just read through again, and yes I think I do see your point.
Whilst it would be possible for you to implement a system to keep count of the refferance count. This would be a duplication of processing use as BMax has already done this internaly.
I see the code Dream posted, and I think I remember reading it as well, I think it got attacked by skid (I think this was the same one, there was a code post, and a thread here as well ). Because when all said and done its "Hack"
However. This is not like when you could change the spectrum font with a Poke. Everyone knew about it, everyone used it, and It would have gone wrong if there realesd a Spectrum version with a different address sytem for the font. Which is where it differs here. Its a valid hack, any code you produce with it will still run even when or if it is changed internaly. (Im not saying it will work if you recompile it, Im just saying and code alredy produced will work).
Now if BRL do change this system, what are they going to change it to? It can only change really in two ways, first the offset from the object could change. (Well youre going to store the ofset as a const anyway, so thats no problem). Or second, this are going to store the information consecutivly for all objects. (But in this case the still have to keep a pointer to point from the object to the number of instances (Or vise versa), and thats easyerky Hackable.
Ultimatly I agree with you, if the information is there inside the engine, and it really would only take a "Object.Refcount", I dont see why BRL dont just add it in. Come on half the command we use are undocumented already.