> On 12 Apr 2016, at 09:44, Thibault Raffaillac <thibault.raffail...@inria.fr> > wrote: > >> I will not add for the moment that predefined types value holders? We would >> need to add one for each type we support to be consistent, and document it, >> and add tests. >> And btw? you do have a generic holder? is just that you need to refine it to >> what you want :) > > Couldn't we use FFIInt32? To me it would make sense to use the class to refer > to the type, and an instance of it for a value holder in memory (this is not > asking for a change, only reporting it looks strange).
nope. we try to hide the border between “in” and “out” to make the FFI experience simpler… but it is there. immutable types (like integers in Pharo) cannot be swap (become) and because of that we cannot make the pack/unpack algorithm to work in any efficient way. The benefit to have this functionality does not pay the performance penalty for doing it (it introduces an extra check for any parameter marshalled). So, for now… no, we cannot… you need to stick with the value holder :( Esteban > >> My advise is that you go with what you need, we can consider add predefined >> value holders later. > > Yep, I am sticking to the basic features as much as possible anyway. > > Cheers, > Thibault >
