Przemek,
IMHO: Yes, I think that it is better don't force the parameters to
string and more thinking of the HRB's power.
I also think that it is very good solution pHrb in collectible pointer:
very sure and avoid possibles memory leaks.
The only thing I dislike is having the new pHrbBodyGC of __hrbLoad()
inside hb_stackReturnItem() and not be able to access without the hacks
explained. Sincerely I believe that also hack inside __hrbLoad() is
more easier for the PRG's coders to have more control.
Best regards,
Xavi
Przemyslaw Czerpak escribió:
On Mon, 07 Jul 2008, Javier wrote:
Hi Javier,
If I have understood well I agree with best solution is automatic
destructors for pHrb type pointer and them automatic call hb_hrbUnLoad()
when release, in other words, do you plan to convert pHrb in collectible
pointer?
pHrb := __hrbLoad( cHrb ) // pHrb it's the unique instance (reference
GC) of this hrb module
pHrb := nil // call hb_hrbUnLoad() and free memory
Exactly. It will be only necessary to implement clean method
for executing EXIT procedures inside .hrb files or to be more
precise: add protection against executing them twice when some
.hrb modules are unloaded from EXIT procedures or in final item
cleanup in hb_vmQuit(). In fact such protection should be added
even for current code.
Another thing that I don't understand, why be forced the parameters to
character as if are from the command line?
IMHO: This subtracts functionality and if they proceed of the command
line also would be accepted.
It was not my decision to accept only string parameters.
I guess it was chosen to emulate standalone Clipper/Harbour
application execute conditions where all parameters passed
to application are strings and each INIT procedure receive
their copy. If you think that it's good to allow also passing
other item types then I can change the code. I can imagine
some situations when it may be useful but of course code
inside INIT procedures will have to be ready for such
situations.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
