Hi :) On Thu 02 Mar 2017 16:47, Mike Gran <spk...@yahoo.com> writes:
> I wanted to make a quick post about the foreign object interface. > This is a bit of a placeholder because I haven't had time to > investigate the interface properly, yet. But I intend to poke at > it soon. > But for there record, there are some problematic design patterns > that I want to make sure can be covered by the new interface. I am not sure that all cases need to be covered by the new interface to be able to include it. I think it would be sufficient to simply replace SMOBs, unrecommend mark procedures and all that, and get the benefits I mentioned in my mail. However that said... > 1. First off is a Lilypond-like pattern. A C++ vector > is used to dynamically add or remove elements. The memory > management of those elements lives in the C++ world. Those elements > are boxed up as SCM. GCing the SCM should not free its boxed > contents, but, deleting the boxed contents from the C++ side > should render those SCMs invalid in some sense. Not really helped by foreign objects AFAIU. > 2. Mutually owned information. Two structures (A and B) both > mutually contain a non-GC-malloc'd structure C. C must exist > so long as one of A or B exist. Likewise, if I understand A and B to be scheme objects of some kind; the pattern here would be a gc-managed wrapper around C with a finalizer, and A and B both use the wrapper. > 3. Here's one from guile-ncurses. An element ITEM is created with > some contents. Default memory management suffices: if ITEM is GC'd, > its contents are GC'd. But the contents of ITEM can later be > attached to a COLLECTION. If ITEM is GC'd when attached to > COLLECTION, its contents are not GC'd. I understand you mean that ITEM has the only reference on its contents, and that if it becomes unreachable, the contents also become unreachable, and may be collected (and possibly finalized if they have a finalizer and finalizers have a chance to run and all the other finalizer caveats). Sure, foreign objects work here, as do any other Scheme data type, right? As long as the ITEM finalizer doesn't finalize its contents. Each contained object needs its own finalizer I think, if finalization is necessary. > 5. Gobject-like subclassing. In Gtk, an application window is > a type of a window which is a type of a widget which is a type of > object. If we were to resurrect an effort on GTK3 binding, > how would it work for foreign objects? This is very tricky; there are lots of considerations here. A new guile-gobject might well want its own scheme. However, yes, foreign objects are subclassable. Cheers, Andy
