| Re: static vs global variable [message #172713 is a reply to message #172709] |
Sun, 27 February 2011 09:55   |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma:
|
Senior Member |
|
|
Leonardo Azpurua wrote:
>
> "The Natural Philosopher" <tnp(at)invalid(dot)invalid> escribió en el mensaje
> news:ikb2fq$o8f$1(at)news(dot)albasani(dot)net...
>>
>> That's maybe possible if you are writing OO code, but it is often
>> simpler when having functions that modify several different variables,
>> to have then as globals, in order not to either pass pointers to the
>> functions, or try and work out a way to return more than one variable
>> from a function.
>
> Hi,
>
> Perhaps I have become thick with the years, but I can't imagine why a
> function should be required to modify several different global variables.
>
Well a simply noddy example is say a program that does a terminal
emulator. The cursor has X,Y coorodintes. Various subroutines are called
to handle keyboard events. They need to modify X AND Y.
There are ways around the 'single return value' that dont use simple
global variables to store the values, but my point is, that its actually
easier and more natural to use them.
> If you don't want to enter into all the details and subtleties of OOP,
> fine. But using and object to pack all the data required by a given
> process, and pass it to any function that might need it is even easier
> than having to remember the names of every global variable involved in a
> complex procedure.
>
It seems little different to me to have to remember a set of class
methods than a set of variable names. If an entity is unique at some
level it needs a unique tag, and you are stuck with having to remember
it, whatever.
> I am completely new to PHP, but it is universal programming common
> sense, like using structs in C, or Records in Pascal.
Well structs/records are a way to package and pass related bits of data,
sure. And things got a lot easier when the compilers I used could return
a struct, and not just a simple integer float or pointer. PHP has its
associative arrays, that perform similar duties.
Still no NEED for OOP.
OOP is supposed to be (as far as a couple of weeks reading it up years
ago suggests), about keeping data and the means to alter it grouped
together and tightly defined BUT....if the methods for altering it are
general enough to be useful, you still can make a mess of the code when
you call the class methods from somewhere else..and it puts a greater
burden on the coders to specify the class interfaces before coding.
Is rather like a database as an 'object' you had better be pretty
rigorous in your table and relationship designs before you start writing
forms to access it.
And if something turns up you didn't think of, you can be in for huge
redesigns if the 'object' has to change to accommodate them.
I fully accept that in a database, this methodology is the least nasty
of all possible approaches. But I wouldn't write a database in PHP.
I suppose my beef is that various programming methodologies have been
developed over the years by people seeking to solve certain problems of
complexity in what they consider more structured and formal ways, and
extend from being 'useful here' to being 'de rigeur everywhere'.
The tool becomes the Rule. 'Gotos should be banned' 'No global
variables' 'Real Men write OOP' etc.
The very worst project I ever worked on, was one where the actual coding
specification had been drawn up from a specification done in Z notation,
as presumably a fashion statement. Months behind, full of programmers
achieving nothing, I finally settled down behind a pint with a fellow
incumbent and asked 'is it just me, or is it true, that say you I and
Fred over there, could throw this lot in the bin and write a system that
worked in three months?' And he said 'true, but it pays well dunnit?'.
In this case the use of some particular formal approach had been dreamed
up by some idiot as a a substitute for actually thinking the problem
through and understanding what the code was supposed to do. I suppose he
had learned it at CompSci, and thought that the methodology was the
problem solving agency, not the analyst.
I am just the lone voice in the wilderness crying out tat befrer you
decide what methods and rules you adopt, sitting down with a sharp
pencil and a sheet of paper and sketching out the nature of the problem
till you understand exactly how you can split it into bits that you can
write clear specifications for you, or someone else, to write code from,
is the most important step. IF your understanding is good, and the
discipline is there, your code will work.
I think it was many years after I had learned to do this that someone
told me what I had been doing was 'structured programming functional
decomposition'. We just called it 'chunking'. :-)
Now if those 'chunks' all seem to map well onto 'objects' all well and
good. Maybe an OOP works. If they map better to procedural subroutines,
use those instead. If what you have is many and various ways of altering
a very very few master parameters, save yourself a lot of overhead and
make those globals.
Tools, not Rules. Intelligent analysis, not slavish adherence to one
formal methodology or language.
Sledgehammers and nuts.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]