newlispfanclub.alh.net

newLisp avoids a garbage collection by nice way - use copying of values in assignments and function calls.
But copying of values is not sufficient to serve real programming needs - and so, we have "contexts" techinics in newLisp, that allows passing by reference.

But, if contexts are subject of dynamic creation and referencing, then they are also the subject of garbage collection!

I'll explain: Suppose, I want to build tree of objects. So, each object will be in separate context, and some of it's variables will contains contexts, holding other objects.
So, I load such tree from somewhere, then found subtree, that I'm interesting for, got the reference to it's root object and then want to destroy whole tree and save interesting subtree for later usage.

With garbage collection I simply will not be worry about that.
But in newLisp I must explicitly copy my subtree to new objects, because the fact of referencing will not protect my objects from destroing.

Possible, here is a point to improvement?

Yes, unreferenced symbols are not collected automatically. If you are into pure object oriented programming than newLISP would not be the right choice.

Objects in newLISP are typically bigger and less dynamic, like: modules, dictionaries, configurations, setups etc..

If you have a program with many smaller objects and a lot of creation/destruction than lists are the better choice in newLISP and adapt more to a general list style of writing programs.

Lutz

Thanks, Lutz!

Anyway, is memory/computation overhead when creating/destroying contexts in inapropriate for many small objects?

[/u]

In the end it all depends on you application, how big it is and what it does.

Lets say you write a graphis based GUI application, in that case I would say context objects in newLISP are a good and appropiate way to do it. As a rule of thumb I would say hundreds or a few thousand objects are OK but when you get into hundreds of thousands of objects then deletion may get too slow, while object creation modification will still be very fast.

Lutz

Thank, Lutz!
That helps.