X# Runtime progress report - continued

Just a quick update to follow up on our report from last week.
Our meeting in Greece last week has brought up a few compatibility problems between X# and Visual Objects, especially in the area of Number <-> String conversions as well as the Transform and Unformat functions.
For some of the problems you could argue that the VO implementation does not make sense. However for obvious (compatibility) reasons we try to make our runtime behave just as insane as Visual Objects.
We will try to resolve most of these this week and when no new problems arise we will upload X# 2 beta 1 end of this week.

There is one important new feature in this build that we would like to announce at this moment and that is support for Dynamic typed arrays.
This feature has been added and sponsored by one customer in particular, but we think it can be usefull for all of you.

Look at the following code for an example and the new syntax ARRAY OF <type>


CLASS Developer
		FirstName := cFirst
		LastName := cLast
		RETURN Firstname+" " + LastName
	// declare a typed array of developer objects 
	LOCAL aDevelopers AS ARRAY OF Developer 
	// Initialize the array with the "normal" array syntax
	aDevelopers := {}
	// AAdd also supports typed arrays
	AAdd(aDevelopers, Developer { "Chris","Pyrgas"})
	AAdd(aDevelopers, Developer { "Nikos""Kokkalis"})
	AAdd(aDevelopers, Developer { "Fabrice""Foray"})
	AAdd(aDevelopers, Developer { "Robert""van der Hulst"}) 
	// AEval knows that each element is a developer, and for types arrays now accepts a lambda expression
	AEval(aDevelopers, { d => Console.WriteLine(d)})
	// The compiler knows the type of the array elements and passes the correct types to the lambda expression. 
	// It can therefore produce early bound and faster code. Of course ALen() also understands typed arrays
	ASort( aDevelopers, 1, ALen(aDevelopers), { x, y => x:LastName < y:LastName}) 
	// Foreach knows that each element is a Developer object
	FOREACH VAR oDeveloper IN aDevelopers 
		? oDeveloper:LastName, oDeveloper:FirstName

In fact all arrays in X# are internally implemented as ARRAY OF. The "normal" array is an ARRAY OF USUAL since each element is a USUAL. Ragged arrays are supported because each array element may also be another ARRAY.
There are implicit conversions between ARRAY OF <Type> and ARRAY, so you can also mix them.
Of course if you assign a normal ARRAY to an ARRAY OF <type> then it is your responsibility to make sure that each element in the source array has the right type.

The "normal"  Ascan(), Aeval(), Asort() etc. take "normal" codeblocks as parameter. These codeblocks will receive USUAL values as parameters and return a USUAL value.
The "typed" Ascan(), Aeval() and Asort() functions will take Lambda expressions as parameters. Asort expects a Lambda expression that takes 2 parameters of the same type as the array elements and returns a Logic.
Aeval expects a lambda expression that takes 1 parameter of the right type. The return type is ignored. 

We hope that you will like this new addition to the language.


  • This is a nice feature. I believe that the dotnet collections are powerful, but not always simple in the syntax. So the new syntax is something in between.

  • Hi Robert,

    Well done. I actually still have some code that I was reluctant to change from codeblocks. This open new possibilities.

    Johan Nel
  • It's hot, so i may miss the point, but why not Array less ?
    Edit: site don't like lesser/bigger, i meant Array followed by type in angular brackets (if that's the term) ;-)

  • [quote name=&quot;Karl Faller&quot;]It's hot, so i may miss the point, but why not Array less ?
    Edit: site don't like lesser/bigger, i meant Array followed by type in angular brackets (if that's the term) ;-)


    That would be possible too. In fact the type is implemented in a generic class __ArrayBase of T

    However this syntax is probably easier for most people and it also reflects that this is a sibling of the ARRAY type So it supports AScan(), AAdd(), AIns(), AEval() etc.