Howdy! Andy Wingo <wi...@pobox.com> skribis:
> On Tue 07 Mar 2017 14:44, l...@gnu.org (Ludovic Courtès) writes: > >> I think Mark made two kinds of comments back then: >> >> 1. There were suggestions about the API itself, nothing deep: >> <https://lists.gnu.org/archive/html/guile-devel/2014-04/msg00070.html>. >> Andy, do you know if they’ve been addressed? > > There were a couple points I think: > > In > > SCM scm_make_foreign_object_type (SCM name, SCM slot_names, > scm_t_struct_finalize finalizer); > > Mark suggested it should be "scm_t_struct_finalizer". I.e. with an r. > I can agree but scm_t_struct_finalize is a type that's already in 2.0; > it's just being re-used here. That said we can do the new name + > typedef + eventually deprecate the old name dance. Good point; given the type is already there in 2.0, I’d be in favor of keeping it as is (without the ‘r’). > He also suggested to get rid of some type punning, and indeed now we > have: Perfect. >> 2. A general concern about “API churn” and our ability to support the >> SMOB API in the future, which I can sympathize with: >> <https://lists.gnu.org/archive/html/guile-devel/2015-11/msg00005.html>. >> >> Essentially, (1) it should be easy for people to migrate from SMOBs >> to foreign objects (I think it’s largely a matter of >> documentation), and (2) existing code that uses the documented SMOB >> API should just work in 2.2, possibly with a deprecation warning. > > I am not so sure about about this one. I think it's not accurate to > characterize beginning to replace a 25-year-old C API (SMOBs) as > "churn". I think the point is that there’s lots of code out there that rely on SMOBs and we shouldn’t break it overnight, precisely because that API is this old. Of course, I agree that pushing users towards an improved API is the right thing long term, no argument here. > I will get to Mark's point specifically in a minute but regarding your > points I believe that (1) is somewhat under-documented; the > documentation is more oriented towards new users than migrating users; > we can improve here; and (2) should work fine (the old API is still > there, not even any deprecation warnings currently). Sounds good. > I think Mark's desire (if I understand it) was for the new API to > completely replace the old in all forms, specifically in support for > mark procedures. I really think that (a) we should not support the SMOB > mark procedure interface, as it's both horrible and insufficient for a > moving collector, and (b) that until we have a moving collector (?), we > shouldn't attempt to speculatively standardize anything in this regard. > Basically the arguments from here: > > https://lists.gnu.org/archive/html/guile-devel/2015-11/msg00003.html > > There's still the SMOB API if you need mark procedures, basically, but > hopefully you don't (e.g. when porting GDB to 2.0 I was able to remove > them; they're less necessary in 2.x than they were in 1.8). Some users > still need them, which is why SMOBs are still around :) Understood. I think we’ve achieved our goal if code that is not ready to migrate works the same as with 2.0, which should be the case AIUI. So, green lights for me. :-) Thank you, Ludo’.
