A short message to inform you of things we are working on this moment.
- We are making good progress with the new macro compiler. Most of the features are ready. And performance is very good !
- We have located and fixed almost all of the issues (some of) you have reported with the X# runtime
- We have added support in the compiler for the Xbase++ dialect.
- We have fixed many things in the VS integration. And X# also installs and works with the new Visual Studion 2019 preview
- We have also rearranged the runtime to better support the Xbase++dialect. There is now a separate VO assembly and a XPP assembly. Both share a common RT assembly that contains the common code (such as the USUAL, DATE and FLOAT types)
- We have updated the compiler to the latest version of the Roslyn source code. As a result we have new features (such as the ability to generate reference assemblies ), the new combination of "PRIVATE PROTECTED" which makes a type member only accessible for derived classes in the same assembly and more.
We have not enabled all the new features of the latest C# versions yet. For some of them we still have to invent a syntax. We are considering to add the IN modifier for parameters in one of the next builds. This will declare a readonly reference parameter. This is especially useful when you have a structure as parameter of a method (like the FLOAT or USUAL structures in the runtime). This should result in somewhat faster execution speed since at runtime not the whole structure has to be passed to a function or method, but only the address of the structure. Once we have added this to the compiler then we will also start to use this in the runtime.
There are many other new features added to Roslyn. You can look at this page to see the new features in C# in the last versions.
If you see something that you think is useful for X#, please let us know. And if you have a suggestion for a syntax, that helps too. One other thing we are thinking about is the "is pattern", which combines the "IS" check with the "ASTYPE" operation and creates a variable that has the scope of the IF expression that it is part of :
IF oServer IS DbServer oDbServer
oDbServer:SetOrder(0)
ENDIF
oDbServer:GoTop() /// <- this will generate a compiler error because the scope of oDbServer is the statementblock inside the IF expression
We expect a new FOX release of the product by the end of next week. A public release will follow short before Christmas
If oServer is declared as DataServer then the method SetOrder is not available. So this will not compile.
Robert[/quote]
Now you lost me. I thought the IS clause guarantees, that the next line ONLY gets called, if the type is correct, so, why shouldn't that compile?
In your #2 sample you are tricking the compiler to accept your dataserver object, so, if trickery is needed anyway, why the need for obscure code?
Karl[/quote]
Hi Karl,
at least with the 2.0.0.7 compiler something like
is resolved at *compile* time, and because the compiler doesnΓö¼Γöñt know whatΓö¼Γöñs behind self:server this warning is thrown:
warning XS0183: The given expression is always of the provided ('VO.CheckBox') type
so the code between if ... endif is executed.
When you examine the assembly with ilspy you see:
public virtual method PshBottom([CompilerGenerated] Xs_0024Args params __Usual[] ) as __Usual
//FUNCTION PshBottom() AS __Usual
local num as Long
local server as __Usual
//
num := IIF((Xs_0024Args != null) , Xs_0024Args:Length , 0)
server := Server
if (true)
Functions.__InternalSend(Server, "Gaga")
endif
Functions.__InternalSend(Server, "GoBottom")
return self
regards
Karl-Heinz
Now you lost me. I thought the IS clause guarantees, that the next line ONLY gets called, if the type is correct, so, why shouldn't that compile?
In your #2 sample you are tricking the compiler to accept your dataserver object, so, if trickery is needed anyway, why the need for obscure code?
[/quote]
This is the risk of examples out of context. I will post a more detailed example on the forums later.
Robert
at least with the 2.0.0.7 compiler something like
is resolved at *compile* time, and because the compiler doesnΓö¼Γöñt know whatΓö¼Γöñs behind self:server this warning is thrown:
warning XS0183: The given expression is always of the provided ('VO.CheckBox') type
so the code between if ... endif is executed.
When you examine the assembly with ilspy you see:
public virtual method PshBottom([CompilerGenerated] Xs_0024Args params __Usual[] ) as __Usual
//FUNCTION PshBottom() AS __Usual
local num as Long
local server as __Usual
//
num := IIF((Xs_0024Args != null) , Xs_0024Args:Length , 0)
server := Server
if (true)
Functions.__InternalSend(Server, "Gaga")
endif
Functions.__InternalSend(Server, "GoBottom")
return self[/quote]
Hopefully it's because it is friday afternoon, or Robert's remark re out ouf context hits the mark, but what's the link between your first sentence and the warning? What ensures that server is always of type checkbox?
Karl
didnΓö¼Γöñt read the warning carefully - seems I also need a break.
good question - i donΓö¼Γöñt know. itΓö¼Γöñs the first time iΓö¼Γöñve tried such a "expression IS datatype" ...
regards
Karl-Heinz
Good job!
But most of all we are waiting for DBFCDX and MEMVAR. Without them, we cannot start transferring projects from VO.
Best regards,
Leonid.