Re: cvs: /php3 ChangeLog

At 23:23 24/11/1999 , Sascha Schumann wrote:

On Wed, Nov 24, 1999 at 10:57:20PM +0200, Zeev Suraski wrote: At 22:24 24/11/1999 , Sascha Schumann wrote:

I like the approach of simply removing the username/password from the hashed-details and always doing a change_user() on a pconnect. That shouldn't be hard to do and I will take a whack at it today.

    Urgh, another layer for a special version and more
    precompiler directives... one day, someone should clean up
    mysql.c.

    To see what I mean have a look at php3_mysql_do_connect(). It
    should be at least split up into multiple functions.

Well, I'm not sure where's your frustration comes from. Actually I do, but it's such a typical case of backwards compatibility that I didn't expect you to get upset by it.

    I'm not upset, but I tend to prefer clean and readable code.

I do too, and yes, a large amount of #if logic hurts readability. Long functions do not in my opinion; If you have a single logical unit it can be inside a function, even if that function ends up being 200 lines long. I never believed in the 'every function has to be at most 30 lines' rules. do_connect() is a single logical unit, and I see no reason to break it into pieces. The only thing that repeats itself is the connect code, and I personally don't like wrapping single lines in functions. I looked at the code; It can be made more readable by removing some directives and using some macros. Quite frankly, your words about do_connect() being a mess were pretty irritating, considering it was and still is a sound foundation for mostly all of PHP's database modules, and IMO, a pretty good one at that. It needs no rewrite, it needs some cosmetic changes.

It's as simple as that - we can decide to drop support for earlier versions of MySQL, or we can choose to have code that has compiler directives in it. You say it calls for dividing it to subfunctions? Perhaps, even though I personally don't think I agree.

    The advantage of splitting a large function into multiple
    functions would help in this case to

    - avoid redundant code (i.e. you have the same code multiple
      times to connect to the database)
    - avoid massive use of preprocessor directives (i.e. have
      multiple versions of the same "subfunction". The right one
      can be chosen by a preprocessor directive. That frees the
      main function of dozens of directives.)

By design, it had no directives at all. Directives may have been added along the years as new MySQL features appeared. It has nothing to do with design.

        Quoting Zeev Suraski:

    "I'll refamiliarize myself with my old code [...]"

    If the author of the code needs to "refamiliarize" himself
    with his code, the code cries for a rewrite. Just imagine how
    lost someone completely unfamiliar with the code will feel.

I completely disagree with you. You think I remember each and every part of Zend? I sure as hell don't and don't ever plan to. It doesn't mean it cries for a rewrite, it means it's large-scale and perhaps somewhat complex (and because it does complex things, not because it's badly implemented). I write code on plenty of other projects other than PHP, and I never remember exactly what I wrote, and yes, I have to refamiliarize myself with the code if I don't touch it for several months. In this case, I believe the last time I touched the connect code was over a year ago. And again, I just looked at the code. It took me roughly 2 minutes to figure out what's going on. Refamiliarize may have sounded as if I had to study this function for a couple of hours, but I merely meant I should reread it. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/