> I did not want to use extra container for GC pointer. This code operates on > low level things like GC mark and programmer must know how GC work, so I do > not think it can not use hb_gcRefInc/Dec. These functions are not more > internal in that context. > > I do not think there is something special in cairo. These GC references was > implemented just a few weeks ago, so, I think cairo is only one of first code > that started to use it. > > I've tried to look at OLE implementation, and this does not look very clean > to me. In HB_OLE GC structure, pCallback is a pointer to PHB_ITEM (not > PHB_ITEM itself) and it points to callback item from ISink object from > ActiveX. It is not obvious that ISink object will not be released before > HB_OLE will be destroyed (otherwise HB_OLE->pCallback can point to random > memory content). hb_gcUnlock in olecore.c:248 is much more difficult to > understand, that hb_gcRefInc/Dec in cairo code. I understand that there is a > little different situation callback support. Storing pointer to PHB_CODEBLOCK > is touching internals of Harbour VM and you could not store PHB_CODEBLOCK in > HB_OLE, but in cairo code GC block containing cairo_t* is not a hidden > internal - you need to operate on it. Though, all such code is placed in > hbcairo/core.c and not accessable from outside.
This is not my concern. My concern is that no non-core code should ever use private APIs, or use any internals. This is a very basic rule and if we don't follow it we will end up with problems eventually (like suddenly breaking code, maintenance problems, uncontrolled incompatibilities and unclear dependencies between components). This can be solved in two ways: - To user public APIs in non-core code - To make private APIs public. I can't argue about the details, or which approach to use because for me both OLE and cairo are not comprehensible solutions at this moment. It seems hbcairo code now has two solutions, which IMO should be reduced to one which complies with this basic rule. (while keeping proper functionality of course) [ Now both solutions use internals. ] Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
