| Re: static vs global variable [message #172718 is a reply to message #172713] |
Sun, 27 February 2011 14:56   |
Leonardo Azpurua
Messages: 46
Registered: December 2010
Karma:
|
Member |
|
|
"The Natural Philosopher" <tnp(at)invalid(dot)invalid> escribió en el mensaje
news:ikd71r$a2b$1(at)news(dot)albasani(dot)net...
> 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.
Well, X and Y do not qualify as "several". And in that particular case
having a Cursor class would be extremely helpful: in your code you
write "cursor->goto($x, $y);" and the cursor goes to that point
"magically". If later have to write an emulator for other terminal,
all you have to do is change the definition of the Cursor class
instead of browsing through all the code.
> 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.
> 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.
IDEs do help a lot in this respect. Sadly, I still haven't found an
IDE for PHP, but in most of them, once you write the name of an object
followed by a dot (I guess it would be by -> in PHP) you get a nice
little window with all of the object public members. So, it is easier
to remember the name of a set of "packers" than the names of
everything packed inside them.
> 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.
It alsa has Objects, that do the same. Nobody says that an object
_must_ contain code.
> 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.
If you have to call the code from somewhere else, then it doesn't
belong into that particular object, and packig it there is a design
error that will force you to do nasty things. The right action in that
situation would be to move the general code somewhere else.
> The tool becomes the Rule. 'Gotos should be banned' 'No global
> variables' 'Real Men write OOP' etc.
It has nothing to do with dogmas.
Unrestricted usage of gotos may lead to excesively complex code. OTOH,
a goto jumping outside a deeply nested structure allows for greater
simplification. The actual rule is not that gotos should be banned,
but that simplicity must be sought.
One of the nastier bugs I ever had to solve was because of a global
variable being modified at some point deep inside a chain of calls,
destroying the original value at the calling point. And there was no
need for the variable being global in either of the two points. Ih I
had been particularly careful, the bug wouldn't have occured. But if I
had avoided the use of global variables, unless they were strictly
needed, the need for extra care wouldn't have existed, neither the
bug.
I always tought that real programmers only wrote assembly code using
EDLIN.
> 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?'.
Managers, specially when they come from a Management School and not
from the field, can be pretty dumb.
OTOH, I can't imagine how to keep a group of programmers in sync
without a lot of formalization. But I have never needed to manage a
large team, nor been part of any, except for my first years as a
programmer, when I was given a HIPO spec, coded the routine, validated
it with a test program that came as part of the specification, had it
punched and handed the cards pack upwards when it was ready.
Anyway, there's a spanish motto that says that "everyone descends the
stairs how they best like".
--
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]