- Multiple member objects declared on a single line.
Shape circle, square;fails, expecting a semicolon. I'm curious what the reasoning behind disallowing this is.
- Compound assignments on property accessors.
I saw your justification for disallowing these in another thread, but I submit that having an option to enable them (signifying an understanding of the consequences) would be immensely useful to myself and others. C++ does far naughtier things with implicit code at times.
- Casting value types to booleans.
I understand why reference types cannot be allowed to cast to booleans (checking null-ness), but why this restriction should apply to value types baffles me a little. I'm mostly bothered about this due to the problem below, which has caused me to register many of my engine's reference-types as value-types. Though I also rather like being able to keep terse syntax like
if (Keyboard.x && keyboard.y.pressed()) {}
//as compared to
if (Keyboard.x.down && keyboard.y.pressed()) {}
- Reference types and C++ smart pointers.
Don't consider this one a criticism of the language; I understand very well that this is a nightmarish design challenge. (I've read your remarks in another thread about the matter.) But some thoughts:
I have a reference-counted pointer type in my program and many objects that hold such pointers to inner classes containing their actual data. Hence, a "Shape", for instance, can be cheaply passed around, its contents shared, and can be null. While this is the very notion of a reference type, it didn't jive very well with Angelscript, forcing me to register it as a value type. This is a shame because it behaves *exactly* like a reference type in C++, even being capable of null-ness.
//Rough idea of my C++ class
class Shape
{
class Data
{
//Data members are here in a private class
};
//The actual methods are in the reference-like class
Method();
OtherMethod();
RefCountedPtr<Data> data;
}The principal issues arise from the fact that the "Shape" instance is itself a reference. It's capable of being "null" separate from the angelscript handle to it being null, and the native side of the engine may have another copy, meaning a separate reference count would need to be used for keeping track of the trivial Shape object itself. The latter is manageable, but the former really isn't.
[color=#a9a9a9](Based on the fact that the Shape class happens to be one word in size not counting its vptr it would be possible to hack an extremely ugly solution by way of manual object splicing, copious shell functions and some other abominations but I'll just let the impracticality of this approach be its own evidence.)
I don't know the first thing about the inner architecture of Angelscript, but it occurs to me that if such a class could be treated like a value-type internally (with regard to copying, assignment, other handling in the script engine), but act like a reference type in code and implement a few special behaviors for its handle-ness (null-check, retain, release) it would facilitate graceful handling of both smart pointers and the rather more exotic setup I use. I understand this would likely break support for certain containers, though.
...I also understand it might be prohibitively, ridiculously impractical depending on how reference-type handling works in the script engine. Don't consider it a suggestion, let alone a demand. More like an idea. Let me cast my value types to booleans and I'll be happy as a clam.
