I’m curious about the entries that are not linked to the docs. I’m particularly interested in the Await and Async values. I know what they are in .net and I’m hopeful these suggest the future for the Xojo language. Also curious about #tag… any thoughts?
I know the #tag phrase is used as a delimiter of sorts in the text-based project files. For example, if you open a *.xojo_window file in a text editor (be careful not to make any changes to the file), it’s the very first thing you see.
As for Await and Async, I found mention of it here http://documentation.xojo.com/resources/release_notes/2016r2.html“…Compiler ‘Async’ and ‘Await’ are now reserved words…”. It may have some unknown internal use, but maybe somebody was thinking ahead, at the time?
I’m curious about the entries that are not linked to the docs. I’m particularly interested in the Await and Async values. I know what they are in .net and I’m hopeful these suggest the future for the Xojo language. Also curious about #tag… any thoughts?[/quote]
several of these have been reserved for a long time - just in case
For instance WITH, OF, ASYNC and AWAIThave been reserve for many years
Async has been reserved since at least 2017r1.1 if not longer if you try
btw
i wish xojo can differentiate between variables/properties and key words/classes.
so often i will use a name and its forbidden to use and i need to use a unique ugly name.
Keywords you cannot use in any context EXCEPT where xojo allows - they are completely reserved
Class names you can do just about anything you want but if you do something like
dim tcpSocket as string
// now references to TCPSocket MUST be prefaced with GLOBAL.
// otherwise your code is ambiguous if you mean the local variable or the TCPSocket class
but this is a problem of your own making
Of course you cannot create another global class named tcpsocket as then again you have ambiguity as the existing global one in the framework and yours would both be, fully qualified, GLOBAL.TCPSocket
However you COULD put a new class inside a module, scoped as protected, and THAT one can be named TCPSocket and its fully qualified name would be unique and not clash with the global one in the framework
the compiler can’t but i think something like this is possible and valid for a human.
key word,name,type
assign a value can’t be done with Dim so it must be a variable
dim in a condition would be a variable
[quote]
Dim dim As String
dim = “ABC”
If dim = “Hello” Then[/quote]
i believe my last name conflict was in a container control with my own properties names, so it had a reason.
personally I would avoid this even if a human could figure it out
it ranks right up there with things like the obfuscated C contest and makes code that should be clear, conside and easy to understand harder to read
for instance
dim session as Session = Session
which is not my favourite thing ever as session is a local variable of type Session that is retrieved by a global function called Session
Even though the compiler gets this right its just a practice I would strongly discourage (and it has other implications as do other stylistically similar bits of code)
If you added a property called “name” then yes I could see that would cause problems because inherently every class already has such a property and so you cant have 2 of them
Same goes for all the properties framework classes show in the inspector
There are ways to shadow many properties though - see my blog posts on
Why Shadowing Should Be Avoided
and
Follow up on why shadowing should be avoided
for how to do it “well” if you’re going to do it at all