based on my work with wrapping Irrlicht, the three biggest things i missed were constructors with parameters, method overloading, and manual deletion of variables.
there is the ability to have a static create function which allows parameters, but the problem is that if you subclass, you always need to provide a new implementation because calling subclass.create() without overriding will give you an instance of the base class.
as CoderLaureate stated, as i was converting methods that were overloaded in C++, their definition became much less intuitive in BMX due to needing to have several create methods all named something different. i think this is more of a preference thing though.
maybe its there and i missed it somehow but this is the most import one IMO. being able to retain an object in memory after all reference variables have gone out of scope would be real nice. this could actually be simulated fairly easily (ya... easy for me to say anyway) by allowing direct access to the reference counter for an instance via 2 functions, RefInc(obj:Object) and RefDec(obj:Object).
for example, some psuedocode could be:
yes giving access to the ref counter opens the sytem up to leaks if the counter is not manipulated correctly, but i think taking that risk is worth it. most of the time the garbage collection would be used anyway, but if need to do something special you could.
there is the ability to have a static create function which allows parameters, but the problem is that if you subclass, you always need to provide a new implementation because calling subclass.create() without overriding will give you an instance of the base class.
as CoderLaureate stated, as i was converting methods that were overloaded in C++, their definition became much less intuitive in BMX due to needing to have several create methods all named something different. i think this is more of a preference thing though.
maybe its there and i missed it somehow but this is the most import one IMO. being able to retain an object in memory after all reference variables have gone out of scope would be real nice. this could actually be simulated fairly easily (ya... easy for me to say anyway) by allowing direct access to the reference counter for an instance via 2 functions, RefInc(obj:Object) and RefDec(obj:Object).
for example, some psuedocode could be:
Local obj:Object=new Object ' internal ref counter now at 1 Local objptr:Object Ptr objptr=Varptr(obj) RefInc(obj) ' manually increment ref counter so its 2 obj=Null ' ref counter back down to 1 FlushMem objptr[0].ToString() ' its still there!!! RefDec(objptr[0]) ' decrement the counter to 0 Flushmem ' bye bye objptr[0].ToString() ' boom. its now totally gone.
yes giving access to the ref counter opens the sytem up to leaks if the counter is not manipulated correctly, but i think taking that risk is worth it. most of the time the garbage collection would be used anyway, but if need to do something special you could.