Re: Is neko the solution ?

Le 01/10/2011 00:39, johann Sorel a écrit :
> If someone could answers my questions, I would greatly appreciate :)
> - license : are there plans to change the license ? to something more 'free', public domain or give the
copyright to a foundation ? it's not that I don't like the GPL license but I still have a very bad experience
with OpenSolaris which has suddenly change license to something private (thanks oracle again). I guess
you can understand I have a few fears about GPL, it's not a full proof guarantee for the futur.

There are no plans to make the license more private. As the main 
developer of NekoVM as part of my work at Motion-Twin, we are not 
selling any kind of services based on NekoVM or haXe, so we have zero 
commercial interest in doing so (if that can help you).

> - NekoVM : is there a basic IO support in nekoVM, at least to read and write files ? so I could build a parser
Eria ->  Neko with it ?
> - NekoVM : some archive support ? zip, tar, gz, anything ?

The VM itself does not have IO or ZIP support but there are some 
libraries for that : the standard library allows for file io and the 
zlib library allows for compression of archives. For full ZIP/TAR/GZ 
support you need additional code (see 
http://hxformat.googlecode.com/svn/trunk/format/ for a reference - 
written in haXe but running on NekoVM)

> - NekoVM : my language requieres to have some advance reflexion, I want to store constraint informations
on a function arguments, x between 0 and 10 .

You'll need to general additional runtime checks for this I guess.

> - NekoVM : how are objects organize ? in parrot I could store primitives/class/functions in namespaces
and acces them using reflexion. Is there something similar in NekoVM. something like paths or namespaces ?

Objects have a simple table of fields which is a sorted array of 
key/values. Each key is an integer that represents the hashed version of 
the field name. Hashing is done a compilation so runtime access is just 
a log(n) lookup in the object table.

Objects also have a prototype pointer that can be set with $objsetproto 
(see http://nekovm.org/doc/view/builtins). The idea is that if a field 
is not found in the object table it's looked up in the prototype, 
recursively.

This way you can simply encode classes by having the methods in the 
prototype and only the actual fields in the object itself, and chain 
prototypes for inheritance.

You can read more here :
http://nekovm.org/specs#objects

and there :
http://nekovm.org/doc/view/builtins

Best,
Nicolas

--

-- 
Neko : One VM to run them all
(http://nekovm.org)