Igor Stasenko wrote:
> 
> NB Pros:
>                * as well as for plugin, you can create new
> functionality that doesn't exist in any library
>                * no need to recompile plugin/VM when you making a changes
>                * all your code is distributed with the Smalltalk code,
> but there can be
> complications with platforms
>                * fast - faster than any FFI implementation written in
> C, and as fast as plugin primitive or even faster
> 
>        Cons:
>                * ?unsafe? - you have to provide a safety layers
>                (But hey, you have to deal with same sorts of stuff,
> when writing plugin. No magician workers there)
> 
>                * harder to write
> Yes, its harder than plain smalltalk - true.
> But i can't say, that writing an assembler is harder than writing a
> plugin's slang code.
> If you writing a plugin, you should have an expertise, in VM internals
> and how to build VM , etc etc
> and if you writing an native code, you should have an expertise in
> assembler as well as VM internals.
> 
> So, they are different, and definitely much harder comparing to plain
> smalltalk code,
> but which one is easier is hard to tell.
> 

Cool, I'm glad you wrote that.  I've been following your posts about NB, and
from that quick summary, I already have a much better understanding of where
it fits into the "external code" picture.

Sean
-- 
View this message in context: 
http://forum.world.st/FFI-Documentation-tp2225148p2225585.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to