On Thu, Feb 12, 2015 at 2:42 PM, Nick Wellnhofer <[email protected]> wrote: > I wouldn't mind if we hid more of Clownfish's internals.
Yes, absolutely. Clownfish continues to carry some artifacts from the way it evolved: it was not spec'd out and then implemented from scratch but instead factored out of Lucy, which has been kept working continuously the entire time with comparatively few changes to its API. Overall, having a concrete use case has been extremly positive, but some decisions made for the sake of expediency have resulted in misfeatures and defects in the visible Clownfish interface. The sooner we clean up those messes, the better. Implementing LockFreeRegistry as a Clownfish class made it straightforward to write Perl bindings and tests for it, but turns out not to have been an optimal design choice. I'll work up a pull request. > Another example is > Atomic_cas_ptr in Util/Atomic.cfh. We have to carry around a bunch of > feature macros just for a single inline function that's only used > internally. +1 Clownfish should not be in the business of providing atomics as a user-level feature. Perhaps one day we will discover that they need to be in generated binding code for Clownfish-powered libraries, but I'm pretty sure that at present we only use them in the code which ends up in the main Clownfish shared object. > It would be nice if we could mark certain .cfh files for internal use in a > parcel so they wouldn't be installed. Hmm, adding a feature that allows us to take away features. :) Marvin Humphrey
