> On 13 Jan 2016, at 11:32, Esteban Lorenzano <esteba...@gmail.com> wrote: > > So, recapitulation: > > I want to introduce: > > 1) package renaming, from FFI-NB to UnifiedFFI > 2) prefix renaming, from FFI to UFFI (I will not change method prefix, they > will remain ffi* so this is maybe a problem…) > 3) method renaming, from ffiLibraryName to ffiLibrary (we didn’t talk about > this, but I’m introducing it because is better name :P)
But isn’t the answered object a string? Then I would vote for #ffiLibraryName. Otherwise I’d expect a “Library” object. > > I *think* #2 can be skipped, but #1 and #3 are a must. > > opinions? > > Esteban > >> On 13 Jan 2016, at 11:28, Esteban Lorenzano <esteba...@gmail.com >> <mailto:esteba...@gmail.com>> wrote: >> >>> >>> On 13 Jan 2016, at 03:46, Ben Coman <b...@openinworld.com >>> <mailto:b...@openinworld.com>> wrote: >>> >>>> Le 12/1/16 17:58, Denis Kudriashov a écrit : >>>> >>>> Hi >>>> >>>> UFFI reminds me UFO which can be translated like Unified Foreign Objects. >>>> And objects outside image look really like unidentified flying objects. >>>> It's just address, blob of bytes and they fly outside smalltalk world >>>> And it has some relation to Alien name. >>>> But maybe it is too much funny name >>> >>> I guess we are considering... >>> >>> Prefix: UFO (shorter) >>> Package: Unified Foreign Objects (longer) >>> >>> Prefix: UFFI (longer) >>> Package: UnifiedFFI (shorter) >>> >>> I like your thinking, but I have mixed feelings. Name is cool. The >>> shorter prefix may be a benefit (though the "I" doesn't add much). >>> But it implies more semantics as an external "object" than external >>> blobs of memory (for example) for C libraries. >>> I like "Unified" because it brings together parts of several >>> implementations (if I understand correctly) and fixes a point of >>> divergence at the VM level making it harder for limited resources to >>> collaborate there. >>> So in the end I think I prefer Unified. >> >> yes, I suppose you are right. >> but I was not considering changing prefix from FFI to UFFI, just repackaging >> as UnifiedFFI :P >> >> now… probably I will do it (not many changes to adapt and probably better >> for understanding in the long way). >> >>> >>> cheers -ben >>> >>> P.S. As I understand it, NativeBoost performs a bit better than >>> UnifiedFFI, but it hindered cross-architecture compatibility - but >>> UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if >>> its technically feasible for NativeBoost to become a plug-in backend >>> for UnifiedFFI, that could be used is special circumstances that >>> super-performance is required only on supported platforms? >> >> actually (though I do not test it since a couple of months) it should be >> more or less compatible… it was at the beginning, then I made some changes… >> what is not compatible anymore is the vm who needs to be changed to use >> executable memory. >> >> Also… yes, NativeBoost is faster (callouts, not callbacks) because you >> cannot compete with ASM, but you can compite in activation time and >> optimised code… so who knows, in the future that advantage can not exist >> anymore. >> >> cheers, >> Esteban >> >>> >>> >>> >>>> >>>> 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com >>>> <mailto:esteba...@gmail.com>>: >>>>> >>>>> Hi, >>>>> >>>>> People has pointed (and they are right) that the name of the new FFI >>>>> front-end is misleading. >>>>> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for >>>>> short) is a better name… and to keep packages prox. to regular FFI I was >>>>> thinking on rename FFI-NB packages to FFI-Unified… but maybe is better >>>>> just >>>>> to rename them as UFFI or UnifiedFFI… >>>>> what do you think? >>>>> >>>>> Esteban >
