> On 13 Jan 2016, at 12:56, Max Leske <maxle...@gmail.com> wrote:
> 
> 
>> On 13 Jan 2016, at 11:32, Esteban Lorenzano <esteba...@gmail.com 
>> <mailto: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.

no, it will answer a string or a children of FFILibrary (for instance LibC), 
that’s how we deal with different platforms (like libc.so.6, libc.dylib, etc.)
Originally it was like you said, but it changed… I just forget to refactor it. 

Esteban

> 
>> 
>> 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
>> 
> 

Reply via email to