[DUG] Variables stored

[Jeremy North]

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
>