New to X# and need some direction

[NickFriend]

I do understand c# so not a problem

Yes I know, but I still always feel guilty posting C# here!

It all comes down to style and personal choice as ever. I must admit I now tend to program in a very verbose way - I like to see everything clearly laid out, and I find VS a very productive environment and easy to use with large amounts of code (I can hear Dick throwing rocks at his screen). But that's personal choice, and I can understand the attraction of eg. pre-processor directives and it's a very good feature in X#.

Unfortunately like many I had to move on before X# was ever conceived... I did try to do it in Vulcan, but we all know what happened there. So now I have a huge code base in C#, and I've learnt to love curly braces, semi-colons and case-sensitivity

Nick

[lumberjack]

Hi Wolfgang,

for properties I prefer the short syntax. Instead of

Code: Select all

property MyProp as string
  get
    return _cMyProp
  end get
  set
    _cMyProp := value
  end set
end property

you can write

Code: Select all

property MyProp as string get _cMyProp set _cMyProp := value

I do realise it and do use it also most of the time except for descriptive [educational] purposes.

Look at the end of my response to Nick regarding static vs. singleton. My implementation with the use of #command is even less typing.

Code: Select all

PROPERTY MyProp AS STRING GETSET _oMyProp
PROPERTY MyProp AS STRING GET _oMyProp
PROPERTY MyProp AS STRING SET _oMyProp

And then the hot from the development team included in X# Version1.2 (Exclusive Johan Edition)

Code: Select all

FORCE SET PROPERTY Config1 AS STRING GETSET oConfig1
FORCE SINGLE SET PROPERTY Config2 AS STRING GETSET oConfig2

Regards,

[lumberjack]

Hi Nick,

It all comes down to style and I find VS a very productive environment and easy to use with large amounts of code (I can hear Dick throwing rocks at his screen). But that's personal choice, and I can understand the attraction of eg. pre-processor directives and it's a very good feature in X#.

Well I realise that. Throwing rocks? Well my screen was hit by an atomic bomb reading that

Unfortunately like many I had to move on before X# was ever conceived... I did try to do it in Vulcan, but we all know what happened there. So now I have a huge code base in C#, and I've learnt to love curly braces, semi-colons and case-sensitivity

I would strongly recommend you move backward... Ever heard of ILSpy Plug-in for X#? Can quickly teach you how to un-love curly braces, semi-colons and case-sensitivity

[FFF]

Johan,
don't like shooting - but just for clearness: IIUC, we talk two different things:
a) translating C# to X#, where one has to handle names which differ semantically by their casing
b) syncing varying casing with NO semantical difference, i.e. sloppy typing
If so, i'm all with you for b), for a) i'd have thought, making a tool to automatically rename e.g. "name" to "_name" would have been easier, than to modify the compiler.

Happy coding!
Karl

[lumberjack]

Hi Tom,

Hi Johan, thanks for this, yes looks like I am learning something new again. Can you confirm this is what I think I see:
The MYOB Object is much like a Global Hidden class instance that we can access through functions but no direct referencing except since X# is fully OO, we have no functions..... this is why I could not find them

Well not 100% true, although FUNCTIONS do not exist we still have functions.

Code: Select all

BEGIN NAMESPACE MyStaticClasses
STATIC CLASS MyFunctions
  STATIC METHOD Left(s AS STRING, len AS INT) AS STRING
    VAR sLeft := s:SubString(0, len)
  RETURN sLeft
EMD CLASS
END NAMESPACE

Lets say we want to call Left()

Code: Select all

FUNCTION Start() AS VOID
  VAR myString := "This is a very long string"
  ? MyStaticClasses.MyFunctions.Left(myString, 4) // Result will be "This"
RETURN

However we want to do less typing:

Code: Select all

USING MyStaticClasses
FUNCTION Start() AS VOID
  VAR myString := "This is a very long string"
  ? MyFunctions.Left(myString, 4) // Result will be "This"
RETURN

Ok not much less typing, lets try again:

Code: Select all

USING STATIC MyStaticClasses
FUNCTION Start() AS VOID
  VAR myString := "This is a very long string"
  ? Left(myString, 4) // Result will be "This"
RETURN

Voila we have a "function"!

HTH,

[ic2]

Hello Nick,

[quote="I find VS a very productive environment and easy to use with large amounts of code (I can hear Dick throwing rocks at his screen). [/quote]

That would be a waste of my screen . But even then, people finding VS productive mainly amaze me.

You mean you got used to it. I got used to it too, in C#. But getting used to it doesn't mean I often wonder how designers of a language could pick the worst possible solution (=the one causing the most problems, extra time etc) for almost very basics of the language. I think after they setup C# they were promoted to the Microsoft department developing VS, where they were allowed to continue their destructive work.

But I'm glad for you you like it.

Dick

[NickFriend]

I've learnt to love curly braces, semi-colons and case-sensitivity
You mean you got used to it.

Hi Dick,

No I mean exactly what I said.

Having a compulsory line end character means my code continues until I tell it to stop. So it's always absolutely clear where a line of code ends.

Curly braces give an instant visual signal of how my code is nested and the scope of things like a using statement. Together with the excellent automatic code formatting of VS it makes complex code very easy to read.

And case sensitivity just makes you more careful and precise about how you write your code - look at the example of Tom's AccountService code - that could never happen with case-sensitivity.

Nick

[ic2]

Hello Nick,

1 Your ";" remark makes sense to me. Note that we used the same character to tell VO to continue on the next line but I've always found that quite unreadable. On the other hand, I nearly always put code on one line with the HD monitors nowadays, or separate code in multiple lines in the program myself. Then I wouldn't really need the ; and will forget it from time to time but ok, the compiler is usually clear telling this.

2 I find the {} making code indentation unreadable. It is very difficult to follow which opening bracket matches which closing bracket and hence it often happens to me after some editing that I get a compiler error because I accidentally deleted one with no clue where. I undo and start over again. VO's IF (ENDIF) CASE (ENDCASE) FOR (NEXT) are much, much clearer to show where something starts and ends and if I have a lot of ENDIF's I added some comments to which IF they belong. Different END keywords make code more readable than the same end }.

I am not sure on which page I can find code which goes wrong without a case sensitivity but I can give you an easy sample of where it goes wrong - easily.

Myvar=10
....
MyVar=20

Now we calculate something adding MyVar but in intellisense we see MyVar first and use it - adding 20 instead of 10 without really realizing it. Calling the 1st one MyVarForThis and the 2nd MyVarForSomething else is a much better idea and it intellisense will give you the exact case. I can't think of any situation where the same variable with different casing is useful unless for creating confusion.

Dick