No, such kind of type-cast is not possible.
Chora belongs to the family of static typed programming languages. The Chora compiler expects to know the datatype of every operand it evaluates during the compilation time.
Let assume you have following code section:
var Views::Text view = new Views::Text;
view.String = "Hello world";
When evaluating this code the Chora compiler is able to deduce that the variable view is an instance of the class Views::Text. Accordingly the next following write access to the property String of this instance is legal because the class Views::Text does implement such property. The Chora compiler can verify it.
Now, let assume the class of the view is unknown at the compilation time:
var class someClass = GetSameClassAtTheRuntime();
var someClass view = new someClass;
view.String = "Hello world";
In this case the Chora compiler is not able anymore to deduce what the view is. Depending on the value returned from the imaginary method GetSomeClassAtTheRuntime() the view can be anything, it can be a text view, an image view or an instance of your own GUI component.
In one case such instance may implement a String property so the next following write access could work. In another case (e.g. when the method GetSameClassAtTheRuntime() returns Views::Image), no String property is available. The access would result in a crash or the application would behave unpredictable.
The static typed characteristic of the Chora programming language ensures thus that the developed application is verified already at the compilation time avoiding such errors as described above. Additionally the knowledge about the datatypes of all operands and expressions allows the code generators to generate well optimized target code.
Thus the remaining question is, for what is the class datatype suitable?
In its main application case it is used almost always together with the new operator. In this manner it allows the creation of instances of classes not specified at the compilation time.
Let assume in your application you need to show different menu components (e.g. PictureMenu, AudioMenu, SecurityMenu, ...). Every component is implemented as a separate class. The unique aspect all these classes have in common is that they all are derived from a basic menu component:
Application::BasicMenu
+--- Application::PictureMenu
+--- Application::AudioMenu
+--- Application::SecurityMenu
+--- ....
Furthermore let assume that you have an application component which is responsible for the transitions between the menus (it shows the menu). And also let assume you want the application component to be implemented without having any dependency to the different menu classes. The following code demonstrates it:
var class menuClass = GetMenuClass();
var object anObject = new menuClass;
var Application::BasicMenu menu = (Application::BasicMenu)anObject;
if ( menu != null )
Add( menu, 0 );
else
throw "GetMenuClass() returned a not menu class.";
At the beginning of the code we call an imaginary method GetMenuClass() to determine the class of the desired menu component intended to be shown. Then in the second row an instance of this class is created. Please note, the variable anObject is declared with the datatype object. This is a consequence of the usage of the new operator with a class operand. As described above the Chora compiler is not able to deduce the exact datatype of the returned object. Uniquely it can deduce that it is an object.
The magic happens in the third row. Here we perform a dynamic cast from the unspecified object to the menu base class. This dynamic cast evaluates the inheritance of the given object and verifies whether it is really derived from the class Application::BasicMenu. Should the cast fail, then the variable menu will receive the value null. This is tested in the following if condition. If succesful, the menu can be shown on the screen using e.g. the Add() method.
The approach implies thus that all classes intended to create instances with a particular new operator have to share a common base class. It is an advanced and powerful technique when designing flexible GUI frameworks able to be extended later without having to adapt the implementation of the framework itself.
