randomguy12345

----------
http://alexzuzin.com...imp-my-library/
refer to the above url, in scala
Implicit type conversion is a simple idea with powerful repercussions. Scala lets you define methods that convert an instance of one type into an instance of another – say, a java.lang.String into your.own.SuperString. When such a method is in scope (properly imported), you can use a java.lang.String anywhere you need to use your.own.SuperString, and the compiler will automatically call the converter method. Here’s an example adapted from the venerable library Scalaz:
class BooleanW(isTrue: Boolean)
object BooleanW{
implicit def BooleanTo(b: Boolean): BooleanW = new BooleanW(b)
implicit def BooleanFrom(b: BooleanW): Boolean = b.isTrue
}
If, like above, you define conversions both to and from the new class, you essentially get the ability to extend a class or trait and use the extension in all existing APIs – just like Ruby’s open classes, but with static type checking. This pattern is so useful that it has its own name – “Pimp My Library.” It’s pervasive in Scala – you’ll see and use it a lot. The specific additions to existing types are usually described as “pimps.”
-------------
Now, in angelscript:
I will like to ask that if I have a class ZFraction (value type) and I want that if somebody wants to make lots of objects and its mathematics, then whether I can define somekind of "Implicit" data conversion function (without explicit casting or constructor pattern), so that string can be converted to ZFraction by that function. This will really ease the scripting to real scripting level.

ZFraction frac1 = "22/3"; // i want to use like this

ZFraction frac1 = ZFraction("22/3"); // i do not want to use(pseudocode): ZFraction frac1 =ZFraction("22/7") spewn all over my source code
ZFraction frac1 = cast <ZFraction>("22/3") // i do not want this pseudocode spewn all over my source code. Though this is fine for "explicit" data type conversion, but it is not good for "implicit" data type conversion

http://www.angelcode..._hierarchy.html
mentions that
Hierarchies can currently only be registered for reference types, not for value types.
why is it so. is it a design choice?


I mean , if i have value type(for performance reasons) of "ZFraction" and "ZIrrational" . Now i would definitely like them to be a subclass of "ZReal".
Just due to the above restriction, i will be forced to use reference type, which will make the performance poor, as it heap based.

Sory for the trouble.
This is probably the last language feature - i am asking about .

whether "closures" are supported or atleast are in the immediate roadmap.

Actually, first moving into the task of exposing my C++ classes into angelscript, i need to make sure that the angelscript or any scripting language is apt for me.
Right now, i am evaluating between
NullC ( http://code.google.com/p/nullc )
and angelscript
and some other choices .
and the closures and exceptions are my main humble requirements from the scripting language or should atleast be in the immediate roadmap.
Thanks in advance

When i am going through this url article published in july 2010
http://fog-framework.blogspot.com/2010/07/type-safe-scripting-engines-for-c.html

it is listing the disadvantage of angelscript regarding exception as
"Only text exceptions, no try-catch blocks in the code. Exception is something that shouldn't happen and it's handled by the your C/C++ code."


is it really "still" so, or it has been added

( I am asking this , because one disadvantage of angelscript listed here,
"No inheritance for C/C++ classes. This makes the scripting engine totally unuseful for GUI ".
This disadvantage is removed, i know. So i am hoping that whether the above thing (which i have asked about) has also been done
)
hence, to restate the question: "whether try catch i can do in angelscript or not"?

is there a support for mixin
http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/
http://groovy.codehaus.org/Runtime+mixins

http://en.wikipedia.org/wiki/Mixin

(this will solve my current problem regarding inheritance of many utility functions from classes.)