Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / User type name possible restrictions?

Author
Message
mr Handy
12
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 25th Aug 2013 22:52 Edited at: 25th Aug 2013 23:00
Hi!
Is this sample code 100% safe and correct? The names "data" and "exit" are even here looks "reserved", also can type name be same as variable ("super")?



Rudolpho
14
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 26th Aug 2013 12:15
It shouldn't be allowed for clarity but I guess it should work depending on the compile order.
If it compiles it is most likely safe to use. You can always put a data-type indicating prefix on such fields though, like bExit for a boolean, dwData for a dword etc. Types are reminiscent of a restricted struct so I tend to prefix those with an s where "necessary";



"Why do programmers get Halloween and Christmas mixed up?"
mr Handy
12
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 26th Aug 2013 13:48 Edited at: 26th Aug 2013 13:50
If exit is integer and I try to pass a string value to it, the error appears:
Quote: "Cannot perform 'integer' cast on type '$$1' at line 13."

Is that mean exit is not a real name? Also AFAIR (but not sure) there was an error report about variable like varA@varB or @varA.varB, like it's name was a single word.

And what about "dim super() as super"? Is type is a variable or what? Because such line causes no error.

TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 26th Aug 2013 13:58
Quote: "And what about "dim super() as super"? Is type is a variable or what? Because such line causes no error."


It's safe, but bad practice.

You should use the "_t" suffix for types for clarity:



I also recommend not using keywords for variable names. Just don't do it. DBP is kind of screwy.

TheComet

mr Handy
12
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 26th Aug 2013 14:28
If two variables can't have the same name obviously, why type can have?

TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 26th Aug 2013 16:09 Edited at: 26th Aug 2013 16:09
Quote: "If two variables can't have the same name obviously, why type can have?"


No it can't.

This causes and error:


Types and variables can have the same name, but doing that is discouraged.

TheComet

mr Handy
12
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 26th Aug 2013 16:19
I mean this


Rudolpho
14
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 26th Aug 2013 17:12
Because they are different kinds of constructs.
A type name is only relevant to identify a type during compilation. As such it is relevant when it follows the type keyword as well as after as. Besides that it is never used (if variable X is of type T, this will just be a numeric reference held by the pre-/compiler; it's name is not used beyond declarations).
Likewise the array names are held in a different table. The same goes for variables, functions and subroutines I suppose. As long as they occur in different sections, a shared name is without consequence. However it introduces ambiguity if used in any place where constructs of more than one kind, where a identifier name is shared, can be used. For example as argument to a function that can take both an integer (variable) or an array. I'm uncertain how many such constructs there actually are in DBPro though.
I suppose the "if exit" may translate into "if exit()", which is why that fails. However the exit function has no return value (and quite frankly isn't even a function but rather a loop control). Or maybe it doesn't work because the if clause parsing actually rules out any reserved words (such as exit) to prevent ambiguity and strange bugs. If so, all functions / constructs should however, but it seems they don't. Sloppy compiler mayhap?


"Why do programmers get Halloween and Christmas mixed up?"
mr Handy
12
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 26th Aug 2013 17:37
Not very understand

So type name could be same as array name?
And two types can has same variables inside? (see my previous post example)

TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 26th Aug 2013 18:22
Quote: "So type name could be same as array name?
And two types can has same variables inside? (see my previous post example)"

Yes.

TheComet

mr Handy
12
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 26th Aug 2013 19:49
Thanks, guys! I think I get it now. I hope At least, if I fail at naming compiler should tell me

Login to post a reply

Server time is: 2020-08-04 05:59:47
Your offset time is: 2020-08-04 05:59:47