> On Mar 31, 2020, at 3:06 PM, Blake Bender <bben...@pivotal.io> wrote:
>
> We in this instance means the native client team. As far as specific
> comments, I'm going to suggest we not go down that road, because this feels
> a little more adversarial to me than it needs to be already.
Sorry it feels adversarial. From below I think there is a misunderstanding of
my preferences.
> Suffice to
> say that from my own perspective, in both what you wrote and what I got
> from our in-person conversation on Monday, your answer to the general
> question "Should the C bindings be part of the native client?" appeared to
> be no, thus a separate repository seemed a perfectly reasonable
> assumption. I had hoped to do this in the geode-native repo to begin with,
> so your assent to this makes life easier.
This may be the point of confusion because I have never intended to give the
impression that the C-bindings should be separate from the geode-native repo.
My examples even integrate it with the geode-native project. I do believe it
should be separate sources and separate includes. I would not want to be doing
a C++ project and have C functions clouding my IDE or vice versa. Perhaps that
is where the confusion comes from.
> As far as my concerns about inefficiency, what I meant is essentially yes
> we have multiple copies of the same code in the release, and this always
> makes me a little uneasy. I've seen a lot of compatibility bugs in my
> career having to do with different products having different versions of
> the same code, so my natural inclination is to avoid it when possible.
> Having both C++ and C-style functions exported from the same library
> doesn't give me any heartburn at all, so simply compiling the C bindings
> into the existing shared library just means one less copy of the code in
> the installation. I fear I am in the minority in this opinion, however,
> and it's not something I'm really doctrinaire about, so I'll defer.
I would really like to understand your concerns but I don’t understand how
combining the symbols into a single file resolves the versioning issue? Can
your help me understand what the different produces with different versions
means and how it would apply to this case?
If the C and C++ symbols are both exported from the same shared library would
you have a common include directory as well or would you spit the includes? I
could live with a combine library but not a combined include headers.
> So are we good here? I'd like to get the RFC wrapped up and move on to
> building this.
Do you feel there is a consensus? I feel like there is a lot left that isn’t
either in the original RFC, hasn’t been discussed here or is still a sticking
point. You could update the RFC with what we have discussed and see if
consensus is reached.
Sticking points:
* Single or split shared libraries
* Single or split includes
* Single or split source repository
Undefined:
* Exception handling (I gave one example but didn’t get feedback or consensus)
* Namespacing/Prefixing
* Pattern and naming conventions for new, delete and class methods.
* Handling of (de)serialization hand off or callbacks into non-C code
Agreed:
* Strong types with opaque struct pointers
* No complete structs in the API/ABI
-Jake
