Foreign object API

[ludo@gnu.org (Ludovic Courtès)]

Mark H Weaver <mhw@netris.org> skribis:

> Deprecating and replacing the SMOB API is a significant event in the
> history of Guile.  It should not be rushed, nor should it be finalized
> until it supports existing use cases and anticipated future
> developments.

Agreed.

> As an aside, I'm not happy with the fact that this new foreign objects
> API was pushed to the stable-2.0 branch less than 25 hours after the
> initial proposal was posted.  It feels like establishing "facts on the
> ground", and sets up a situation where the burden is now on me to argue
> that it's not ready to be included in 2.0.12, whereas the burden should
> rather be on you to obtain a consensus that this new major API is ready
> for release.

Agreed too.

But we had already agreed on both long ago.  :-)

> For now, I would prefer to revert the commits that added this new API,
> to enable the immediate release of 2.0.12.  Then we can have a proper
> discussion about what a SMOB replacement API should look like, and make
> sure that both past and future anticipated use cases are covered before
> releasing it.

I sympathize with your concerns.  (I wish we had had this discussion
long ago, when Andy pushed the foreign objects API, or when I called for
us to “do something” about it so we can release 2.0.12.)

Could you summarize your practical concerns with the foreign object API
so we can decide whether reverting is the best thing to do to move
forward?

I expressed mine in
<https://lists.gnu.org/archive/html/guile-devel/2015-05/msg00005.html>
to which Andy replied on IRC the other day that (roughly; correct me if
I’m wrong):

  1. GOOPS is faster in 2.1.

  2. In 2.4 we may be able to avoid loading GOOPS altogether, but not
     before that.

  3. It’s OK if foreign objects introduce some overhead compared to
     SMOBs in 2.0, because the addition of this API in 2.0 is for people
     who want to write forward-compatible code where overhead is less of
     an issue.

  4. Even though some primitives are turned into primitive-generics,
     there are no observable semantic differences when GOOPS is loaded.

  5. Using structs as I suggested above appears to be undoable for
     obscure reasons.

I am not fully convinced, but I prefer to live with that than with a
frozen project.

Besides, it is clear to me that the SMOB API is here to stay, as is, in
the 2.2 series and probably the 2.4 series as well.  I believe Andy
agrees with that.

Don’t escape this thread people, you’re trapped!  :-)

Thanks,
Ludo’.