On 29 November 2012 08:29, Torsten Bergmann <[email protected]> wrote:
>>and i am not really happy with that. I prefer having 9 methods in Object 
>>>than 9*100 methods in many classes.
>
> What about having just one single method on Object called #externalCaller (or 
> just #external) that returns an object understanding the
> callout protocol.
>
>   self externalCaller call: 'whatever'
>
> This wont overload Object but may require some fiddling since
> "thisContext sender" is used.
>
>
... and this is what new api 'self nbCallout' provides.

>
> I also dislike the "namespacing" using "nb" in the selectors.
> What if you rename or replace the project in the future?
>
> I would have to rename my methods from ffiCall: to alienCall:
> to nbCall: ... ;)
>

a solution to this problem: use own convenience method(s)..
then if you will ever need to get rid of namespace, all you need to do
is change few methods.

> Yes I know it is a different interface protocol from FFI to
> NativeBoost - but still nobody is interested that the
> subproject is called FFI/Alien/NativeBoost once it is
> integrated in standard Pharo.
>
> You just want to do an external call like in any other
> language and you are just interested that it works
> reliable and easy.
>
>
> And I would vote for a simple pragma <externalCall>
> instead of
>
>    <primitive: #primitiveNativeCall module: #NativeBoostPlugin>
>
> Sorry for all the wished ... but Christmas is near ...
>
did you behave well this year? you know Santa do not likes bad boys :)

If serious.. we're evolving.. and it takes time and effort to change skins.
Once we will be ready to get rid of namespace prefix, then we can abandon it,
but not right now.

> BTW: I marked 1.6 as release
>               1.7 as stable
>               1.8 as new development in the config
>
> We can also mark 1.7 as release since there was an official
> announcement from Igor. Version 1.8 should get new developments.
>
> Thanks
> Torsten


--
Best regards,
Igor Stasenko.

Reply via email to