December update

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


15 comments

  • "IF oServer IS DbServer oDbServer"
    something missing? If not, i don't see this as intuitive ;)

    Applause for progress, little sniff, still no news of CDX...
  • - We are working on CDX. It is not ready yet
    - The new IS Pattern syntax (which is a proposal, so if you have a better proposal please let us know) replaces this:

    IF oServer IS DbServer
    VAR oDbServer := (DbServer) oServer
    oDbServer:SetOrder(0)
    ENDIF

    So this is shorter
  • IIUYC, the construct should prevent that SetOrder fails, because it's object has no such method? Then why not "oDBServer?:SetOrder(0)"
  • Hi Robert, DBFCDX is essential for me as the dictionary for all my VO applications is DBF based. DBFCDX is what I need most for the migration. Other enhancemente are very welcome, but not essential for me.
    Wolfgang
  • Karl,

    The code gets a oServer which could be for example declared as DataServer and could be an ArrayServer, SqlSelect or another subclass of DataServer.
    In case it is a DbServer then it wants to call SetOrder.

    I know that many people do it like this in existing code now:
    IF IsMethod(oServer, #SetOrder)
    Send(oServer, #SetOrder,1)
    ENDIF

    This works, but is slow (both IsMethod and Send need to use reflection to lookup type information). The proposed change does produces faster code and also has type checking on the parameters of the SetOrder.

    An alternative approach would be to use the ASTYPE in combination with the syntax that you suggest:

    LOCAL oDbServer := oServer ASTYPE DbServer
    // oDbServer will be NULL_OBJECT when not a DbServer
    oDbServer?SetOrder(0)

    But if you have many likes of code that need to be executed for the oDbServer you do not want to check for null (Conditional Access) in every line of code.

    Robert
  • Robert,
    i see. But don't get, why you need a clone var.
    For this scenario i'd want to write
    IF oServer IS DBserver
    oServer:SetOrder()
    Endif
    I think that 3-liner is immediately understandable. The proposed shortcut syntax IMHO is not.
  • [quote name=&quot;Karl Faller&quot;]Robert,
    i see. But don't get, why you need a clone var.
    For this scenario i'd want to write
    IF oServer IS DBserver
    oServer:SetOrder()
    Endif
    [/quote]
    If oServer is declared as DataServer then the method SetOrder is not available. So this will not compile.

    Robert
  • [quote name=&quot;Wolfgang Riedmann&quot;]Hi Robert, DBFCDX is essential for me as the dictionary for all my VO applications is DBF based. DBFCDX is what I need most for the migration. Other enhancemente are very welcome, but not essential for me.
    Wolfgang[/quote]

    Wolfgang,

    DBFCDX is not forgotten. But I am afraid it will not be available before Christmas.

    Robert
  • [quote name=&quot;Robert van der Hulst&quot;]DBFCDX is not forgotten. But I am afraid it will not be available before Christmas.[/quote]
    Thank you! I look forward to it!
    Wolfgang
  • [quote name=&quot;Robert van der Hulst&quot;][quote name=&quot;Karl Faller&quot;]Robert,
    i see. But don't get, why you need a clone var.
    For this scenario i'd want to write
    IF oServer IS DBserver
    oServer:SetOrder()
    Endif
    [/quote]
    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