One quick glance of an experienced eye allowed to understand the blurred
and almost unreadable Daniel C. Bastos's handwriting:
[color=blue]
> In article <pan.2005.04.14.19.44.45.538648@example.invalid> , JDS wrote:[color=green]
>> On Thu, 14 Apr 2005 12:03:08 +0000, Daniel C. Bastos wrote:
>>[color=darkred]
>>> I disagree with your didacticism. I tell myself to go ahead and try
>>> my own ideas and see if they work well. If they work well, then they
>>> work well. I consider myself unexperienced in programming in general,
>>> but I think I started progressing when I decided to drop all of these
>>> ``lessons''. I don't think level of knowledge matters, do you?
>>>
>>> I think it's better to think for yourself. Someone tells you ``it's
>>> better to write a function for this one specific case'', you should
>>> think ``Why?'' and see if you can find reasons in favor and against
>>> the statement. I think you truly learn this way.
>>>
>>> [...][/color]
>>
>> Think for yourself, yes. But there is no point in reinventing the
>> wheel.[/color]
>
> I probably agree with you here. I say ``probablly'' because
> reinventing the wheel is a bit necessary sometimes for learning. But
> ``reinventing the wheel'' is a vague expression in this context. Let
> me give you an example.
>
> If I want to learn how ``insertion sort'' works, I will read
> publications about it and attempt to write it from scratch as if I was
> inventing it myself, so I'm re-doing it, copying it, but trying to
> make sure that I understand every step of it.
>
> By no means I imply that this is the best method. I do it this way
> many times because the knowledge I have tells me so and I'm satisfied
> so far.
>
> But you see, this isn't exactly reinventing the wheel because I am
> only following someone's steps just to try to see what she saw. And
> this is a didactic method I use myself. IMO, this is different from
> writing insertion sort in a different way (reinventing the wheel).[/color]
Agreed. I wrote an authentication through SessionID myself in PHP just to
know how it is being done. I could use SESSIONS, but I preferred to
write it myself the first time.
[color=blue]
> [...]
>[color=green]
>> In the case of programming, I was being didactic about *technique*
>> issues.
>> Not *style* issues. There are many tried and true reasons why globals
>> are not usually the best solution for a problem -- and it often does
>> pay to learn from people who have tread there in the past.
>>
>> I was not suggesting a style or preference as better than another. I
>> wouldn't do that (well, I try not to), and I think that if you learn
>> enough of the "why" behind my blanket "don't do that" statements
>> against
>> globals, you would see the difference. Maybe you do.[/color]
>
> What I see is that, specially in PHP, many times global variables are
> really not the way to go. I agree with that. I rarely use global
> variables in PHP, but I do sometimes, when I need a global
> variable. :D Now, you could argue on ``Do you really need it when you
> think you need it?'' and we would need specific cases.[/color]
If I have a value that has to be accessible to all the parts of my script
and has to be possible to modify (which is VERY rare), I will use
globals. Globals are a tool, and like any tool they might be misused.
But, like every tool, they ARE useful sometimes.
Cheers
Mike
