X-Sharp
Improvements request for VOXporter
I am porting an extensive library from VO to XSharp with the X# VO XPorter. The VO XPorter is doing a good job. But there is still room for improvement. I have the following wishes for the VO XPorter, because I will use it even more often.
Method Axit()
I once learned that the Axit() method should return NIL as a RETURN value. For this reason my Axit methods look like this:
method Axit() class …
…
return NIL
It would be a great help if the VO XPorter could remove the NIL behind the RETURN when porting the method to DESTRUCTOR(), because otherwise the X# compiler generates a warning XS9032.
Method Init()
Similar to the Axit() method, my Init() methods end with the following code:
return self
Again it would be a great help if the VO XPorter could remove the SELF behind the RETURN when porting the method to CONSTRUCTOR(), because otherwise the X# compiler will generate a warning.
Assign with RETURN-Value
Similar to the methods Axit() and Init() all my assigns end with the following code
return self
Again it would be a great help if the VO XPorter could remove the parameter after the RETURN when porting the assign, because otherwise the X# compiler will generate a warning XS9032.
Furthermore it would be great if the typing could be removed for strong typed assigns like the following one, because the X# compiler generates a warning.
assign Caption as string pascal class ...
Chris
I have seen many assigns with a single line Return Self:_fieldname :=newvalue
Make sure you don't remove these assignments.
In the compiler I change
Return <exp>
to
Var $somevar := <exp>
Return
Robert, yeah, I am planning to change only the exact specific ones provided in the report, RETURN SELF and RETURN NIL, nothing else
Hi Chris,
Again it would be a great help if the VO XPorter could remove the SELF behind the RETURN when porting the method to CONSTRUCTOR(), because otherwise the X# compiler will generate a warning.
When I transported some of the code from VO to XSharp, I removed SELF after REUTURN in each constructor, since the compiler generated a warning. And I also thought, why didn't XPorter do it? I wanted to ask a question on the forum, but then I thought that this was an obvious thing, and if it was not done, then it probably should be. But it turned out I did not understand correctly :)) If you implement this, it will be good. As for me, I still have a lot of code with classes to transport.
Best regards, Leonid
It would also be nice to generate AssemblyInfo.prg when transporting an App or DLL from VO to XSharp, as is done if I create a new library in XSharp.
Hi Leonid,
That's because VOXporter needs to check and adjust dozens and dozens of things in the code and other areas of the VO app, in order to make it possible to compile it in .Net with as less changes as possible, so we give priority and implemented first the most critical aspects. Having a RETURN SELF in a constructor is harmless, so it did not get priority. But we still keep adding such "quality of life" improvements as time permits.