[DUG] Variables stored
Robert martin
rob at chreos.co.nz
Fri Jan 21 15:17:38 NZDT 2011
Hi
There are some things wrong with global variables and they should be
used where appropriate. I only made a point of saying better to avoid
as they can seem easy for a newbie, who could end up using them for
everything.
Cheers
Rob
On 21/01/2011 3:07 p.m., Jeremy North wrote:
> There is nothing wrong with global methods (somehow .NET made then
> seem uncool for native languages)
> There is nothing wrong with global variables (when used in moderation)
> Like Jolyon, I see no reason for assignable typed constants (which I
> think were kept for backwards compatibility)
>
>
> On Fri, Jan 21, 2011 at 12:36 PM, Ross Levis<ross at stationplaylist.com> wrote:
>> I use some global variables. I also have what I assume are other bad habits
>> like creating plain functions or procedures instead of declaring them inside
>> the form class. Just lazy.
>>
>>
>>
>> Ross.
>>
>>
>>
>> From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz] On
>> Behalf Of Jolyon Smith
>> Sent: Friday, 21 January 2011 9:44 AM
>>
>> To: 'NZ Borland Developers Group - Delphi List'
>> Subject: Re: [DUG] Variables stored
>>
>>
>>
>> Assignable typed constants are pointless.
>>
>>
>>
>> If you are going to declare a constant and then use a compiler switch to
>> make it behave like a variable, then be honest and just use a variable!!
>>
>>
>>
>> Typed constants cannot even be used where “normal” constants can be:
>>
>>
>>
>> const
>>
>> ONE: Integer = 1;
>>
>>
>>
>> procedure Foo(aIndex: Integer = ONE); // ERROR: Constant expression
>> expected
>>
>>
>>
>> or:
>>
>>
>>
>> case iValue of
>>
>> ONE: ; // ERROR: Constant expression expected
>>
>> end;
>>
>>
>>
>> Remove the type declaration from the ONE const, and both compile just fine
>> (note that this is independent of the Assigned Typed Constants compiler
>> setting).
>>
>>
>>
>> A typed constant is to all intents and purposes a variable, and might as
>> well be declared as such (note that you can initialise a unit variable as
>> part of it’s declaration):
>>
>>
>>
>> var
>>
>> ONE: Integer = 1;
>>
>>
>>
>>
>>
>> One final comment – Delphi really has no concept of a “global” variable.
>> The highest visibility is “unit variable”. You still have to explicitly
>> “use” a unit to bring it into scope, and if two units declare variables of
>> the same name normal scoping rules apply but you can explicitly qualify a
>> reference using the unit name if you need to override the default scope.
>>
>>
>>
>> Most of the time global/unit variable is close enough that the distinction
>> doesn’t matter, but when it comes to dogma the old rules that “global
>> variables are the spawn of Satan himself” needs to be tempered in Delphi
>> with the fact that they are a bit better “behaved” than the sort of global
>> variable that those ritualistic rules were originally devised for.
>>
>>
>>
>> However, it is still true that the occasions when a unit variable is called
>> for are relatively few, but they should not be simply outlawed for being
>> something they are not.
>>
>>
>>
>> J
>>
>>
>>
>>
>>
>>
>>
>> From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz] On
>> Behalf Of Robert martin
>> Sent: Friday, 21 January 2011 09:18
>> To: NZ Borland Developers Group - Delphi List
>> Subject: Re: [DUG] Variables stored
>>
>>
>>
>> Hi John
>>
>> While all you suggest may be true (I don't know about the compiler setting
>> stuff) I would strongly recommend anybody starting out with programming /
>> delphi avoids using global variables. Its a nasty habit to get into :)
>> Also the compiler setting you talk about sounds dangerous as someone who
>> didn't know about it could become highly confused looking at the code or
>> trying to compile it on a fresh install of Delphi !
>>
>> Also note I changed the typo spelling of the subject because it was annoying
>> me :)
>>
>> Cheers
>> Rob
>>
>> On 21/01/2011 9:04 a.m., John Bird wrote:
>>
>> There is another way as well, you can declare simple global variables –
>> depending where you declare it determines it’s scope - how visible it it is.
>>
>>
>>
>> In this example string2 can be seen by any unit that uses this one, just as
>> Form11 (the particular instance of TForm11, and is also a global variable)
>> is visible.
>>
>>
>>
>> String3 can be seen by all procedures in this unit, but not by anywhere
>> else. If you have lots of simple variables to store and they don’t need
>> to be inherited etc this is the simplest way to do it.
>>
>>
>>
>> You can take this further:
>>
>> If I have lots of constants to declare, or variables to store I create a
>> unit which is code only (no classes) eg called storeunit and declare all the
>> constants and variables I want there, any form or unit that wants access to
>> all these variables just has to add storeunit to its uses clause. This
>> centralises all such declarations in one place away from a form and is very
>> tidy. I will often put simple global functions and procedures in here too,
>> as they also become globally available, eg various standard ways for
>> formatting dates and strings. Also this unit can be uses in different
>> projects as well. For this just go to File/New/Unit and the IDE gives
>> you a new blank unit already to add stuff to – a simpler unit with no form
>> or class stuff.
>>
>>
>>
>> Here string4 string5 integer1 integer2 integer3 can all be seen from
>> anywhere that uses Storeunit
>>
>>
>>
>> It depends on whether you like using global variables or not. Also its a
>> good idea to use a clear naming convention for such variables.
>>
>>
>>
>> There are other tricks you can do too - you can alter compiler settings to
>> allow assignable constants for a procedure, then any values assigned here
>> will be preserved between calls to the procedure. But that seems to be
>> confusing to me, as it really becomes a variable and not a constant. I saw
>> that used in and example where the program wanted a counter of the number of
>> times the procedure was called, and the counter constant in the procedure
>> was assigned a new value each time the procedure was called, its quite a
>> tidy way to do that sort of thing. In this case the scope (visibility) of
>> the variable is totally limited to the one procedure.
>>
>>
>>
>>
>>
>> type
>> TForm11 = class(TForm)
>> Button1: TButton;
>> procedure Button1Click(Sender: TObject);
>> private
>> { Private declarations }
>> public
>> { Public declarations }
>> MyString : string;
>> end;
>>
>> var
>> Form11: TForm11;
>>
>> string2: string;
>>
>> implementation
>>
>> uses storeunit;
>>
>> {$R *.dfm}
>>
>>
>>
>> var
>>
>> string3: string;
>>
>> procedure TForm11.Button1Click(Sender: TObject);
>> begin
>> MyString := 'Hello, world!';
>>
>> string2:=’Hello world2’;
>>
>> string5:=’Hello world5’;
>> end;
>>
>>
>>
>> unit Storeunit;
>>
>>
>>
>> interface
>>
>>
>>
>> var
>>
>> string4:string;
>>
>> string5:string;
>>
>> integer1:integer;
>>
>> integer2:integer;
>>
>> integer3:integer;
>>
>>
>>
>> implementation
>>
>>
>>
>> end.
>>
>>
>>
>> John
>>
>> From: Marshland Engineering
>>
>> Sent: Thursday, January 20, 2011 3:45 PM
>>
>> To: delphi at delphi.org.nz
>>
>> Subject: [DUG] Variabels stored
>>
>>
>>
>> Is there a way to store variables so I can use them from one procedure to
>> another?
>>
>>
>>
>> I have been currently storing them in hidden edit.text boxes on the form but
>> there must be a better way.
>>
>>
>>
>> Cheers Wallace
>>
>> ________________________________
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at delphi.org.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> NZ Borland Developers Group - Delphi mailing list
>>
>> Post: delphi at delphi.org.nz
>>
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>>
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1191 / Virus Database: 1435/3392 - Release Date: 01/20/11
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at delphi.org.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject: unsubscribe
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1191 / Virus Database: 1435/3392 - Release Date: 01/20/11
>
>
>
More information about the Delphi
mailing list