w is supposed to become a object oriented language suited for implementing networked games. One of the goals is to make this as cleanly as possible, which also should make sure that the result can be used for other things as well. The interpreter will for example only contain instructions needed for the various control-structurs, and method calls. Expressions like 2 + 3 will be made into a method call to the operator + in the class int.
The base classes will be written in C++, and then incoroprated in the w binary. Through some clever interface definition language the driver should know about the classes and how to call methods in them. If you ever need more functions or want new types they should be implemented with this mechanism.
The language will feature classes, structs and pointers. Pointers are a troublesome area, since we must make sure that the language is error-free and thus doesn't dereference a pointer pointing to a freed area. The only solution to this problem I've found this far is that you can only get a pointer to instances that has been created with new. It would thus not be possible to get a pointer to a instance that is "auto"-created (ie local variables in a function or and in this case also global variables in a class).
All methods in w will be virtual, no fuzz here. It will however not be posible to use polymorphwheteveritwasnamed on anything but pointers, since it screws up optimization too much otherwize. It should be possible to use virtual inheritance too, but I'm not sure if this should be controlled by the class inheriting or the class you inherit from. Maybe it could be controlled in both...
It will be possible to overload operators and methods in w.
Type-casting will always be explicit in w (I don't like implicit type-casting...). A template-like mechanism will be used to implement abstract data-types. A template will specify a class and then every class inheriting it could be used instead of the template.
All classes will inherit the class any, eventhough it might be empty. Security could also be put here, but that's not necessary.
Restrictions: You will not be able to inherit and add state to some of the fundamental data-types in w, because of the way memory is allocated. It will however be possible to do that from C++.
Memory will be reclaimed by a Baker garbage-collector that will be running constantly (ie no stop the system for a minute to GC).
The w driver will be multi-processed (not multi-threaded). Each object will belong to one and only one process. The processes will communicate with other processes using internal streams. There will also be streams connected to sockets for communications with the outside world. The benefits will mostly be that things like www- or ftp servers become easier to write, and thet wiztools can have functions like find running in the background. It will however not make it easier to write the multi-player part of a mud, since all it's objects must recide in one process.
Security can be provided by restricting which classes might call a certain method. Thus the sensitive system can be put in several objects without compromising security.
You will not have to declare everything before you use it, since that might be confusing, especially if you have classes depending on eachother. So we will have no C++-like .h-files. That means the compiler has to compile every file that the first file is depending on before it can produce code, even classes that it creates using new. That means that the entire mud whould have to be compiled when it booted, not an ideal solution. Therefore I've added a new new, called clone, that takes two arguments, first a base-class and then the acctuall class-name. The class cloned must inherit the base-class (eventhough this is not checked until the code is run), and you can only manipulate it as a base-class (since we don't know what else it can do till we acctually compile it). Clone might take an string arguments to make things work more smoothly.