I just want to make sure you know... If you see something in the APIs that is "too C++" in the sense that it is extremely reliant on very C++-specific idioms, not only in expression but also conceptually, and therefore difficult to map to C or the way any other language would see things, then by all means make suggestions or even add something new on the C++ API to make the C wrappers easier. Don't feel like the C++ API is 100% set in stone and a sacred item that can't be changed. Your design space can extend into the existing interfaces if there are ways to improve them.
> On Oct 20, 2020, at 8:33 PM, Anders Langlands <[email protected]> > wrote: > > Sounds good Scott. Once I’ve sketched out something and we all agree on a > general approach let’s split the bindings into small chunks we can each > tackle and PR piece wise and do the same for the Rust crate? > > On Wed, 21 Oct 2020 at 14:49, Scott Wilson <[email protected] > <mailto:[email protected]>> wrote: > That works for me. I'll start contributing bindings once Anders sends in the > first PR. > > On Tue, Oct 20, 2020 at 5:39 PM Larry Gritz <[email protected] > <mailto:[email protected]>> wrote: >> On Oct 20, 2020, at 1:56 PM, Anders Langlands <[email protected] >> <mailto:[email protected]>> wrote: >> >> Ok so then what I think I’ll do is port the C part of my rust crate over to >> oiio proper, implementing just enough to add a simple round-trip test, is >> load an image, add an attribute to the header, write it out as an exr. Then >> I’ll make a PR so you can comment. Sound good? > > > Awesome. > > And I would recommend that we approach the C bindings piece by piece. I'm a > fan of breaking it up into many small PRs so they can each be reviewed > quickly, one class at a time. Start with the easy ones and along the way I'm > sure we'll hash out the design issues and have a consensus by the time we get > to the big hairy classes. If we try to do it all at once, we could end up > going down the wrong road and only discover when in the middle of reviewing > and integrating an enormous amount of code that we wished we had made some > different basic decision. > > -- lg > -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
