What is the difference of a property and a global constant in uniface - uniface

I can't understand the difference between a global constant and a property in uniface. When should i use a property? When should i use a global constant?

Related

How to manage global variables

I know this is very basic thing but i need to know that how can i declare / assign value / use global variables.
because i have already declared variable global here it is :
now i am adding value which is geeting from server response like
now in console i am getting output in that global variable.
now, my problem is when i use that global variables values as param value to call API it will take ZERO. not getting correct value
Thanks for guide
Just remove var keyword from the local variable where you assign values and add below code instead.
global_userid = ["\(oDict["userResult"][0]["user_id"])"]
global_reqid = ["\(oDict["userResult"][0]["request_id"])"]

Assign value to Swift property

When should I assign value to properties in swift?
What is the difference between
class Thing {
var something:String = "Cool Thing"
}
and this
class Thing {
var something:String
init(){
something = "Cool Thing"
}
}
Actually its quite obvious when value is assigned on init() but when is value assigned when using 1st piece of code and which is the right way to do?
They're the same, but Apple suggests using the default property value pattern "if a property always takes the same initial value" for stylistic reasons. See the note in Default Property Values section of The Swift Programming Language: Initialization, which says:
Default Property Values
You can set the initial value of a stored property from within an initializer, as shown above. Alternatively, specify a default property value as part of the property’s declaration. You specify a default property value by assigning an initial value to the property when it is defined.
NOTE: If a property always takes the same initial value, provide a default value rather than setting a value within an initializer. The end result is the same, but the default value ties the property’s initialization more closely to its declaration. It makes for shorter, clearer initializers and enables you to infer the type of the property from its default value. The default value also makes it easier for you to take advantage of default initializers and initializer inheritance, as described later in this chapter.
You can use any of the 2. The difference is that if you have multiple initializer you might need to replicate the property initialization. Besides that it's just a matter of preference.
They should both be doing the same thing. The main difference for not initializing first would be if you wanted to assign the var as an optional and test for nil. Otherwise assigning the value would be the same.
var something:String?

How to properly set an instance variable with instance_variable_set?

I was looking through the docs for instance_variable_set and saw that the sample code given does this:
obj.instance_variable_set(:#instnc_var, "value for the instance variable")
which then allows you to access the variable as #instnc_var in any of the class's instance methods.
I'm wondering why there needs to be a colon : before the #instnc_var. What does the colon do?
My first instinct is to tell you not to use instance_variable_set unless you really know what you are using it for. It's essentially a tool for metaprogramming or a hack to bypass visibility of the instance variable.
That is, if there is no setter for that variable, you can use instance_variable_set to set it anyway. It's far better if you control the code to just create a setter.
Try looking at accessors for the vast majority of your instance variable setting needs. They are an idiomatic way to have getters and setters for your instance variables "for free" without you having to write those functions.
If you really do need instance_variable_set, it allows the first argument to be a symbol which is the name of the instance variable to set. A colon is part of the Ruby language that is like a "symbol literal": when you type :foo, you've created a symbol with value foo, just like when you type "bar" directly into your code, you create a string literal with value "bar".

Are "class var"s initialized to zero?

I know that, in Delphi, instance variables and global variables are initialized to zero (this has been asked here before).
However, what about static variables (class var)? I would expect class vars to be initialized to zero, just like global variables. But I've seen too many new Delphi compiler features that were still half-baked to assume that it works, without documentation that actually states a guarantee.
The Help has no index entry for "class var". The "Fields" topic mentions class fields, but does not specify whether they're initialized at program startup. And the obvious fix, of explicitly initializing them (class var X: Integer = 0;), doesn't compile ("';' expected but '=' found").
Are class variables initialized to zero? Is there documentation that explicitly states this?
I'm not aware of any documentation that explicitly states it, but class vars are just a special type of global variable, and globals get zeroed.

Are delphi variables initialized with a value by default?

I'm new to Delphi, and I've been running some tests to see what object variables and stack variables are initialized to by default:
TInstanceVariables = class
fBoolean: boolean; // always starts off as false
fInteger: integer; // always starts off as zero
fObject: TObject; // always starts off as nil
end;
This is the behaviour I'm used to from other languages, but I'm wondering if it's safe to rely on it in Delphi? For example, I'm wondering if it might depend on a compiler setting, or perhaps work differently on different machines. Is it normal to rely on default initialized values for objects, or do you explicitly set all instance variables in the constructor?
As for stack (procedure-level) variables, my tests are showing that unitialized booleans are true, unitialized integers are 2129993264, and uninialized objects are just invalid pointers (i.e. not nil). I'm guessing the norm is to always set procedure-level variables before accessing them?
Yes, this is the documented behaviour:
Object fields are always initialized to 0, 0.0, '', False, nil or whatever applies.
Global variables are always initialized to 0 etc as well;
Local reference-counted* variables are always initialized to nil or '';
Local non reference-counted* variables are uninitialized so you have to assign a value before you can use them.
I remember that Barry Kelly somewhere wrote a definition for "reference-counted", but cannot find it any more, so this should do in the meantime:
reference-counted == that are reference-counted themselves, or
directly or indirectly contain fields (for records) or elements (for
arrays) that are reference-counted like: string, variant, interface
or dynamic array or static array containing such types.
Notes:
record itself is not enough to become reference-counted
I have not tried this with generics yet
Global variables that don't have an explicit initializer are allocated in the BSS section in the executable. They don't actually take up any space in the EXE; the BSS section is a special section that the OS allocates and clears to zero. On other operating systems, there are similar mechanisms.
You can depend on global variables being zero-initialized.
Class fields are default zero. This is documented so you can rely on it.
Local stack varaiables are undefined unless string or interface, these are set to zero.
Just as a side note (as you are new to Delphi): Global variables can be initialized directly when declaring them:
var myGlobal:integer=99;
Here's a quote from Ray Lischners Delphi in a Nutshell Chapter 2
"When Delphi first creates an object, all of the fields start out empty, that is, pointers are initialized to nil, strings and dynamic arrays are empty, numbers have the value zero, Boolean fields are False, and Variants are set to Unassigned. (See NewInstance and InitInstance in Chapter 5 for details.)"
It's true that local-in-scope variables need to be initialised... I'd treat the comment above that "Global variables are initialised" as dubious until provided with a reference - I don't believe that.
edit...
Barry Kelly says you can depend on them being zero-initialised, and since he's on the Delphi compiler team I believe that stands :) Thanks Barry.
Global variables and object instance data (fields) are always initialized to zero.
Local variables in procedures and methods are not initialized in Win32 Delphi; their content is undefined until you assign them a value in code.
Even if a language does offer default initializations, I don't believe you should rely on them. Initializing to a value makes it much more clear to other developers who might not know about default initializations in the language and prevents problems across compilers.
From Delphi 2007 help file:
ms-help://borland.bds5/devcommon/variables_xml.html
"If you don't explicitly initialize a global variable, the compiler initializes it to 0."
I have one little gripe with the answers given. Delphi zeros out the memory space of the globals and the newly-created objects. While this NORMALLY means they are initialized there is one case where they aren't: enumerated types with specific values. What if zero isn't a legal value??
Newly introduced (since Delphi 10.3) inline variables are making the control of initial values easier.
procedure TestInlineVariable;
begin
var index: Integer := 345;
ShowMessage(index.ToString);
end;

Resources