xsharp.eu

Hi Robert,

this is really great, thank you very much! It will save a lot of code and keep the code cleaner at the same moment.

I have now tried something different:
and it seems to work. Unfortunately I have to specify the


otherwise I have a compiler error.

It is the same in the in the extended version of this property:
IMHO the compiler should be able to understand the type of return code. Or I'm making a wrong assumption?

Wolfgang

P.S. my test code is attached as XIDE export file

Wolfgang,

Wolfgang Riedmann wrote:Hi Robert,

means this we can use the command preprocessor directive on X# Beta 9?

I have now tried the following code (on a single line):

Code: Select all

#command PROPERTY <n> AS <t> GETSET <v> => ; property <n> as <t>;;; get;;; return self:<v>;;; end get;;; set;;; if self:<v> <> value;;; self:<v> := value;;; endif;;; end set;;; end property

Code: Select all

class File1      
  protect _cCmdProp as string

property myCmdProp as string GETSET _cCmdProp

end class

but it gives the error

Code: Select all

error XS9002: Parser: mismatched input 'GETSET'	16,30	File1.prg	PropertyTest

Wolfgang

You state you have the #command on a single line, then you have too many ";" there should only be 1 between statements and none after the =>

Robert indicated #command will be available around Cologne except if I missed something.

Jack

Hi Jack,

this can be.... But since we don't have the preprocessor I cannot try it out yet.

I can wait, of course. The preprocessor will be a really cool thing, I'm looking forward to use it.

Really, fun has returned to programming thanks to the "Gang of Four"!

In the meantime I will use the short property syntax - I like it very much!

Wolfgang

Hi Robert,

Robert van der Hulst wrote:Jac,

You probably know this already, but the single line syntax for properties is already supported by the compiler:
The GET clause expects an expression, the SET clause expects an expression list.

No I have not known it, well done, good to know. Must have missed it in the "whats new" section.

Regards,

Jack

Jack,

This was probably never mentioned in the readme, since the single line property syntax is also supported b Vulcan.

You can see the EBNF notation for the property on:
http://www.xsharp.eu/help/property.html

Robert

Thanks Robert,

Robert van der Hulst wrote:Jack,
This was probably never mentioned in the readme, since the single line property syntax is also supported b Vulcan.
You can see the EBNF notation for the property on:
http://www.xsharp.eu/help/property.html
Robert

If I remember correctly the #command single line was initially shown before PPOPERTY was available in Vulcan as wrapper to ACCESS/ASSIGN to align it with the then to be released PROPERTY.

The #command was done to not have to GET _var SET _var := VALUE, but shorten it to GETSET _var.

Although thus not 100% needed for a one liner property, I still think the concept of the pre-processor is a beauty and set the Clipper based dialects far ahead of the rest of the XBase pack.

It is however good to have a discussion around it to make people aware of the power that it brings to the language. We can "emulate" many other dialect syntax that the compiler does not understand yet to produce meaningful and useful code.

Jack

Jack,

You are absolutely right that having a pre-processor adds a lot of power to a language.
I think that we can emulate 99% of the FoxPro syntax with the preprocessor as well.

I remember in the past, many years ago in 1993, that there was a product called the "CA-Clipper Compiler Kit for dBase IV". This product, written by Matt Whelan was using UDCs to convert dBase IV code to functions, which were then supplied in the form of a special library.

Most likely I still have a version of that (probably on 5 1/4 floppy disks), so I can have a look and use similar UDCs when we are going to add the FoxPro support.

Robert

Hi Wolfgang,

What you are looking for, is (generic) type inference based on the return type of the method, here's a simplified version of your code:

FUNCTION Start() AS VOID
LOCAL s AS STRING
s := TestClass.GenericMethod<STRING>() // OK
s := TestClass.GenericMethod() // error

CLASS TestClass
STATIC METHOD GenericMethod<T>() AS T
RETURN Default(T)
END CLASS

here you ask the compiler to figure out that the generic argument type of the method is STRING, because the result of that method is being assigned to a STRING var. While I agree that (in this case) it looks straightforward, type inference on return type is not supported by design (it's the same as in c#). Here is a discussion about this:

http://stackoverflow.com/questions/3203 ... ferred-why

Chris

ps. please don't shoot the messenger

Hi Chris,

thank you very much!

In the meantime I'll write the short form
until the preprocessor will be available.

After I'll use it to build the correct code.

Wolfgang

P.S. the only person I would like to shoot sometimes is myself when I'm doing something really stupid (you know several samples...)

Jack,

I tested one of your snippets with the new UDC support and the result is below;


You can see:
- UDC definition is recognized and colored in the preprocessor color
- UDC usage is recognized ans colored as keyword (especially the GETSET, NOTIFY and CHANGE words which are not normal keywords)
- The editor shows the difference between the statement separator semi colon (which is part of the UDC) and the line continuation semi colon, so they are both colored in a different color!
And in the image below you see the preprocessor output:

Robert