This topic contains 2 replies, has 3 voices, and was last updated by 
codifies
2 years, 4 months ago.
-
Posts
-
Getting regular updates by Mark and it seems like very good language progress. Going in the right direction!
I’d be interested to hear what Mark is planning to tackle in the next 2, 4 , 6…12 months for Monkey2 ?
I’m not in any position you give you any official information, but in short; anything can happen next with Monkey.
Long Answer: Mx2 is becoming extremely flexible and far more integrated with pre-established technologies. Recently an automated “wrapping” tool was released to make use of popular C API’s in Monkey, this will enable nearly any API to be “converted” to Monkey given enough initial effort and community support. Honestly, I can see it becoming one of the best things to have in your programming arsenal, alongside C/++ though not a replacement.
That said, as for the next few months. We can definitely expect a lot of interesting discussion on language concepts and Mark will hopefully be in the lab follow his heart in implementing more “core” features while the community uses his tools to amplify Monkey even more based on the discussion.
Personally, I’m experimenting with creating a Linux User Space(command-line tools/basic computing applications) within mostly Monkey code JUST to see if it can be done. xD So far my research is promising! No promises though. Haha.
Personally I’d love to see better support for C structs (embedded arrays of stucts in structs for example) and having C++ classes as “first class citizens” so on declaring them external (and providing prototypes – probably in header files) you could then use them as if they were (optionally none GC’d) MX2 classes.
object finalisers would allow module writers to craftily integrate external libraries in a way that would allow safe integration with mx2’s garbage collector, basically by creating shadow lists of children objects for parent objects (thus protecting children until the parent is destroyed) – and there are a number of other corner cases for having finalisers too, although they are not without their potential issues.
I’d also really like to see 3d physics as an “official” mod, but there’s so much for a one person team that I can’t see it happening in a hurry and for now just using a self made tiny subset of bullet for what I need.
@scurty from what I remember a lot of the lower level libs are on the whole C (as opposed to C++) with largely simple structures (if any) – ie no array structs inside structs – infact even xlib is quite straight forward even when accessed directly from (for example) python.
You must be logged in to reply to this topic.