FOOP destructors?

Started by ryuo, October 11, 2014, 04:09:52 PM

Previous topic - Next topic

ryuo

I've been wondering if it would be a good idea for FOOP objects to be able to define a destructor function. The constructor for FOOP is normally the same name as the context / class of the object. Could the destructor be defined in the same context / class and have the same name as the context / class, but prefixed with a ~ like it would be in C++? I was thinking it would be nice to be able to hook resource cleanup into a destructor or similar function. I can see this being useful to cleanup memory allocated by functions mapped from the FFI. Perhaps it could be called before newLISP frees the cell's memory. The only problem I can think of is when there are duplicates of the object floating around. It would mean that the destructor should only be called when the last copy goes out of scope. Is this in any way practical to implement, Lutz? Otherwise I am happy to continue using manual cleanup, as this is the C way. But having a way to define how to cleanup resources automatically would be nice. Thank you.

Lutz

#1
A FOOP object is a list where the first member is  symbol identifying the class of the object. That list could live anywhere, e.g. assigned to a symbol or as a submember of another list structure. Destroying all objects constructed by a specific FOOP class would mean walking all cell memory, which is very inefficient. There is no single reference point in the system to all the objects created.



But you could improve the manual cleanup by storing all objects of a class in a list referenced by a symbol owned by the FOOP class it belongs too.



Currently only functions allocated through the simple FFI can be destroyed and there memory reclaimed. Functions  imported via the extended FFI using libffi, can currently not be destroyed. In general, primitives and imported functions are seen as something constant in newLISP which live through the entire life of the program.

TedWalther

#2
In my /dev/urandom function defined over in this thread http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=16&t=4864">http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=16&t=4864 it would be useful to have a destructor.  Purpose of destructor would be to do (close fd) to close the file descriptor.



But then I thought about it; how many "random number generator" objects would you be creating and destroying... this use case is contrived.   But having constructor and destructor functions would be useful for things like filehandles that need to be opened and closed, network connections, database connections, etc.  That is, transient things that take up memory and resources.
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence.  Nine months later, they left with a baby named newLISP.  The women of the ivory towers wept and wailed.  \"Abomination!\" they cried.

Astrobe

#3
FOOP. The F should be a P. Every time I try to use it for something more object-y than glorified structures, it falls flat on its face (and even as glorified structures, it's not really convenient out-of-the-box).



I'd rather use contexts for prototype-based objects.



Kind of what the /dev/urandom example actually is.



But of course, the concept of destructor doesn't make sense in this case, because the "object" lives forever. Unless... You wipe it with delete?

The only point of doing that would be to reuse the symbol (eg that object is caught in a loop). So maybe having delete to call the local definition of delete in the context being deleted (if present; otherwise do the usual thing) would make sense. Conversely new could do the same thing (aka call what would be the copy constructor).



But all this can be defined in NewLisp itself, I think. Just call them "clone" and "destroy" instead of "new" and "delete").

m i c h a e l

#4
Quote FOOP. The F should be a P.

:-)





FOOP was never meant to be a complete object-oriented system. In fact, without references in FOOP, it's not possible to write complex OO simulations. Still, it made working in newLISP (a functional programming language) more natural for someone who thinks in OO terms.



m i c h a e l