a plea for an exit() verb, and an include mechanism
As I noted on the features request page on the wiki, I think we need an exit() function. I noticed in my scalefunction.ck example on b-chuck, it would have been good to issue an error message and exit in the bad-parameter value case -- but I don't see exit() in the programmers guide. Also, and include verb to allow inclusion of function modules and header files would be helpful. (Similar to the #include in C...) --Gary ---- Chess: http://chessnut.net/ Homepage: http://garywilliams.org/ Blog: http://tfs_reluctant.blogspot.com/ ChucK Blog: http://b-chuck.blogspot.com/ Resume: http://garywilliams.org/resume.htm Store: http://www.cafeshops.com/tfsreluctant/ Phone: (607) 775-0408 Permanent email: gwms@corninglink.com
Hi Gary!
As I noted on the features request page on the wiki, I think we need an exit() function.
In the (mythical) new releas, there will be. Since a global exit() might be too severe in most cases, we will also have a shred-based exit(). All shreds will be able to use keyword 'me' to refer to itself. Calling me.exit() will exit that shred.
Also, and include verb to allow inclusion of function modules and header files would be helpful. (Similar to the #include in C...)
We are still finalizing how this is going to be done in v2. As it stands, classes already loaded into the VM are accessible (unless deemed otherwise) to subsequent shreds. We would like to reduce/eliminate the need to do explicit includes, but we also need a good way to resolve mutual references (hopefully without a forward reference, like in C/C++). This is very important for on-the-fly programming. We may adopt a modified version of Java's class loader, which figures out the dependencies automatically, but requires filename to match the public class in the file. This is perhaps a little too rigid for our purposes, so we may end up with some hybrid of these. Best, Ge!
participants (2)
-
Gary Williams
-
Ge Wang