TOPIC:

Hi Guys,

This question may be best aimed at Nick as he has the most experience of extended methods and their use.

I am after a way to place together all three of the small sets in the SubX lists shown in the attached image. I need a larger final set which includes all item entries.

I thought it would be easy to chain the EMs for Union, but for some reason I have hit some issues and snags.

Here is what I got to work but I feel there should be another way :-



Any suggestions ?

Cheers,
Phil.

whoops,

images the wrong way around - '_02' should be the working one and '_01' the image where I show what I tried and failed with ............

tricky this stuff - or is it just me today ?

Phil.

Hi Phil,

I haven't really used Union, but the logic of Linq (that the output from one method in the chain is the input to the next) means that this ought to work.Just a thought, but I wonder if local implied means the compiler has trouble with the output... maybe try typing each variable as local List<int> to see what happens.

You could also try Concat() to see if that worked better - clutching at straws!

Or just use AddRange()... probably makes more sense in this context.

Nick

Hi Nick,

Thanks .... but lets forget the clutching at straws approach for now. Union is a great approach and I have used it in SQL to good effect in the past.

Yes, this is just as I thought - output from one EM as input to another - but my first two best shots seemed to fail ;-0((

I will give it another go before I jump to ask Robert if something is amiss.

ROBERT - Help Please !!! ???

I feel that there is something wrong with using Union and only when in a chain.

here is some code to go on :-



and some that appears to work :-



Although I can't show it I have tried all sort of permutations with code snippets and only find the one way works, and that is to split a line.

Can you please enlighten me and possibly others,
Phil.

Oh! - Robert,

You may also be interested in this approach - see image - BUT - it is not chaining EMs which is really what this issue is all about.

I will go and try C# to see what happens there.



Good Luck,
Phil.

Robert,

I have a one-liner, albeit not a chained syntax this seems to work in X# :-



I will now go to C# and try stuff there.

Cheers,
Phil.

Hi again Robert,

According to my recent little trip / foray into C# it would appear that the X# compiler may not be handling chained EMs (extension methods) correctly.

Here is what I did in C# to test :-



I hope this proves useful and helpful to you.

Cheers,
Phil.

Hi Phil,

UNION is a keyword in x#, so you need to prefix it with @@ (as in @@Union()). This way it should work the same as in c#.

Chris

Thanks a bunch Chris,

A simple solution to what felt at this end like a nasty problem ;-0) Well done !

I have now got it all working in a similar simple manner to C#.

X# is really starting to feel very good to me and my coding. Still a lot to learn however, but then learning is fun, even when you are old and past it !!!

Here is my positive proof :-





Best regards to one and all,
Phil.

Chris,

You had better remind me as to where to go to get a full list of the current KEYWORDS in X#.

I am sure I have seen something relating to a list but can't remember.

Thanks again,
Phil.

Phil,

These is a topic X# keywords in the help file. (Under X# Language Reference)

Robert

Okay Robert,

Thanks, I have all the documentation sufficient for the moment, and a bit more perhaps ;-0)

Tomorrow is another day - now the soccer, Man United trying to get to the final round of the League Cup.

Cheers,
Phil.

Okay Robert,

Thanks, I have all the documentation sufficient for the moment, and a bit more perhaps ;-0)

Tomorrow is another day - now the soccer, Man United trying to get to the final round of the League Cup.

Cheers,
Phil.

Hi Robert,

is there really no better solution for that kind of issues?

The word 'union' is clearly used as a method call. Why does it conflict with a reserved word? Should the error message say more about this reason?

Many reserved word are the cost of the verbose XBase language, but leads to issues like this.

Frank

Hi Frank, Chris and Robert,

Particularly since it is only the second occurrence of 'Union' which causes an issue.

See attached image :-



Line 143 appears to work OK !?

And this is reinforced by the blue colouration only appearing on the second occurrence of 'Union' - see below :-



This code does not compile.

I suppose I should have twigged (noticed) what was going on - BUT - because of an earlier case of LINQ query syntax not seeming to colour correctly in my version of VS 2017, I just got on with things and started to ignore all various colouration of the text and command words.

For some reason the current pre-compiler seems to see the two Unions in a different light / way.

Any sort of improvement will certainly be a help - I realise you are juggling a lot of balls in the air, but then you and the Team are 'Magic' !!!! So that's what we expect ;-0)

Cheers,
Phil.

Frank Maraite wrote: Hi Robert,

is there really no better solution for that kind of issues?

The word 'union' is clearly used as a method call. Why does it conflict with a reserved word? Should the error message say more about this reason?

Many reserved word are the cost of the verbose XBase language, but leads to issues like this.

Frank

Some reserved words are also allowed as identifier. Union is not. At this moment UNION is in our 'VO keywords' list which is not allowed as identifier. You will have to prefix Union with @@ to make this work.,

I will move Union to the list of keywords that can be used as identifier, as well as Event (which is often used in VO event handler code).
Any other suggestions ?

Robert

Hi Robert,

I will move Union to the list of keywords that can be used as identifier, as well as Event (which is often used in VO event handler code).
Any other suggestions ?

I would like INSTANCE and maybe FIELD, if possible.

Wolfgang

Robert van der Hulst wrote: Some reserved words are also allowed as identifier. Union is not. At this moment UNION is in our 'VO keywords' list which is not allowed as identifier. You will have to prefix Union with @@ to make this work.,

I will move Union to the list of keywords that can be used as identifier, as well as Event (which is often used in VO event handler code).
Any other suggestions ?

Robert

Does the problem disappear if the code is case sensitive? UNION as keyword, Union as method.

Otto,

Otto Christiaanse wrote:

Robert van der Hulst wrote: Some reserved words are also allowed as identifier. Union is not. At this moment UNION is in our 'VO keywords' list which is not allowed as identifier. You will have to prefix Union with @@ to make this work.,

I will move Union to the list of keywords that can be used as identifier, as well as Event (which is often used in VO event handler code).
Any other suggestions ?

Robert

Does the problem disappear if the code is case sensitive? UNION as keyword, Union as method.

Yes case sensitivity would make things much easier.
However this problem will be solved anyway in the version of X# that will be released this week. I have moved the following keywords to the list of keywords that can also be used as identifiers:

ALIGN, CALLBACK, CLIPPER, DECLARE, DEFINE, DELEGATE, DIM, DOWNTO, DLLEXPORT,
ENUM, EVENT, FASTCALL, FIELD, FUNC, GLOBAL, IN, INHERIT, INSTANCE, INTERFACE,
OPERATOR, PASCAL, PROC, PROPERTY, SEQUENCE, STEP, STRICT, STRUCTURE, THISCALL,
UNION, UNTIL, UPTO, USING, VOSTRUCT , WINCALL

This may lead to confusion when typing, especially if you trust the colors inside the editor.
For example: if you start typing the keyword FUNC




Then it will be black (identifier) but after you add the name of the function then it will become Blue


Some keywords are difficult to be allowed as identifier, because they appear alone on a line and the parser will not know if the word TRY on a line means the beginning of a try statement or a variable with the name TRY.

Well guys,

As ever, Robert is true to his word and version 2.9 of the compiler seems to solve my 'Union' problem / issue.

Take a look at what now compiles and runs in my developing LINQ app - line 179 is where the BIG change has occurred :-



We no longer need a prefix of '@@' for 'Union', and we get no blue colouration either, which previously showed that the parser was seeing the second 'Union' as a keyword, rather than a method name.

Well done TEAM - onwards and upwards ............

Best regards,
Phil.
Wales, UK.