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.