Vincent,
First, sorry for the somewhat rather harsh comments. That should teach me
to comment on stuff soon after getting up, and then not double checking what
I wrote. Please don't take anything personal by any of my comments, as they
are merely comments of a person still needing his morning coffee.
Rather than comment individually, I will make a general conclusion. After
reading this, I get a better picture and a better understanding of some of
your requests, and your points are more clear. While some areas I still
disagree (like the _underscore for varaibles) I think they are more a style
issue (I use _ for variables that are not accessed or changed by the user,
even via methods).
Granted, my OO experience is probably not as great as yours, I still find it
somewhat a tradeoff for PHP to follow strict OO standards.
I understand more your arguments concerning Error handling, the examples
where a little more detailed, and I agree with the seperation of types of
errors.
Some interesting ideas, to say the least.
And again, sorry for the rather harsh comments. It's not the usual me.
Thank you for taking them lightly, and for being able to read the questions
beneath the banter.
Jason Lotito
----- Original Message -----
From: "Vincent Oostindie" <news@xxxxxxxxxxxxxxxxxx>
To: <pear-general@xxxxxxxxxxxxx>
Sent: Wednesday, April 17, 2002 9:55 AM
Subject: Re: [PEAR] Some PEAR remarks
> On Thu, 18 Apr 2002 02:08:47 +0200, Jason Lotito wrote:
> > Quite interesting. Your thoughts are quite complete, and they do make
> > some good points. I find there are some flaws in your arguments,
> > particularly with your "Too Large" remarks, as well as in regards to
> > what PEAR can do in designing an OO library, seeing that PHP simply
> > isn't as OO as many (including I) would like it to be.
>
> Okay, I'll elaborate on some points below, because I think they're not
> absolutely clear. Also, I think it's a misconception that PHP has bad OO.
> It's actually pretty good, as long as you enforce some good rules on
> yourself (like total encapsulation). I have actually written software in
> pure OO languages (Smalltalk), so I claim to know what I'm talking
> about :-)
>
> > My points are below. But like I said, your points are well taken.
>
> And so are yours!
>
> Before elaborating on some of the points below, I'd like to mention that
> my view on PHP is that it's a language meant for scripting purposes,
> preferrably web applications. The 'general' libraries I use should focus
> on that. That means, for example, that I don't need to be able to create,
> alter or drop tables from any kind of database, because I simply wouldn't
> do that in a typical web application. Of course there are always some
> applications that do (as a matter of fact I'm writing one right now),
> but these are so few in number that they don't justify putting that kind
> of complex code in a general library. As another example, I like the idea
> behind PHP-GTK, but I would never use it myself. If I needed to write a
> desktop application, I'd choose a suitable (compiled) programming
> language, and not a scripting language like PHP or Perl. Again, these are
> all personal opinions.
>
> >> I've been browsing the PEAR code to see if I would like to use the
> >> library in my own PHP programming experiences, but unfortunately I must
> >> say that - after examing the code thoroughly - I have decided I will
> >> not do that
> >
> > I have some serious doubts about that, as serveral of your statements
> > leave me to believe that you haven't fully explored the PEAR website,
> > and learned why certain things are done certain ways.
>
> Well, we can probably argue about that forever. I think I looked very
> good at the source, and you think I didn't. Let's leave it at that :-)
>
> >> A question in advance: why are member variables in PEAR prefixed with a
> >> '_'? Sure this is useful in languages like Java or C++ where it's hard
> >> to see which variable is a local one, an argument or a member, but in
> >> PHP this distinction is already clear: all member variables are
> >> prefixed with '$this->' inside a method. And if you use proper
> >> encapsulation, member variables are never accessed from anywhere else.
> >> (And very, very sadly, this is not the case in the PEAR library!)
> >
> > http://pear.php.net/manual/en/standards.naming.php
>
> I know that they're following a standard, but I question the standard, not
> the fact that PEAR uses it :-)
>
> The only use I see is in prefixing private methods with a '_'. But as I
> said, there's simply no need to prefix member variables, as they should
> always be private, and are always discernable by the way they are accessed
> through '$this->'.
>
> >> Let's start at the beginning: with class PEAR. This class is supposed
> >> to be the base class of all new classes (with non-static members).
> >> Examining this code led me to the following observations: - Class PEAR
> >> is large. The file 'PEAR.php' (although containing two classes) is
> >> almost 800 lines. I think that's pretty big for a base class. In my
> >> opinion, a base class should be fairly small. If you take a look at
> >> other (large) object-oriented libraries, you'll see that base classes
> >> are always pretty small, and for a reason: every other class in the
> >> system relies on it, so making it big increases overhead as well as the
> >> possibility of bugs.
> >
> > I don't see how you think 380 lines of code is Pretty big? 800 lines of
> > code? Yes, with comments, and those are some pretty big comments.
>
> The class library I use (and implemented) myself is also fully
> documented in the code, and when I count all lines in all files needed to
> create a connection to a MySQL database, I come to 650 lines, instead of
> the 800 lines for just a base class, or the 3795 lines needed to do the
> same... Granted, my classes don't have so many features as the PEAR
> library, nor are the comments THAT big. :-)
>
> Regarding comments, it's good that they are there, but I also think there
> are too many. For example, I find comments like these:
>
> // }}}
> // {{{ setErrorHandling()
>
> placed between methods in a class, pretty annoying. But again, that's
> personal.
>
> Another point are comments INSIDE a method. Many methods in PEAR are
> pretty large, making them nearly unreadable. As a solution they are
> sprinkled with comments. Another - in my opinion better - solution is to
> break up those large methods into smaller ones, making those comments
> superfluous. The result is less code, less comments, and better
> readability.
>
> >> Class DB is a class with static methods only, and the two most
> >> important ones (factory and connect) either return an object of the
> >> requested type, or an instance of class 'PEAR_Error'. Again, I think
> >> this is not a good separation of 'normal' code and 'error' code. Also,
> >> whenever some code calls one of these methods, it should always check
> >> whether the object returned is the one they wanted, or something else.
> >> This raises a question: how often is this done by your typical lazy
> >> programmer?
> >
> > This is a moot point, considering if they don't check what they are
> > getting back, they aren't really doing their job now.
>
> You are right of course, but shouldn't there be a clear distinction
> between the various sorts of errors that are produced? For example,
> supplying an incorrect DSN to the connect-method (using 'foo' as the DBMS
> to use) is clearly a programming error. Once it's set up correctly, it'll
> remain correct forever. So I don't really want to check for it every time
> I create a connection. On the other hand, if the database server lies flat
> on it's face, I'd like to know.
>
> The answer is - again - to use smaller methods. Instead of jumping
> halfway out of a method with some error object, break a method up into
> two parts. This allows for greater flexibility on the side of the
> application programmer.
>
> > I wonder if you have ever worked in actual production then? Databases go
> > down, connections get changed, things happen. If an error occurs
> > somewhere along the line, I need to know about it. The idea that once
> > code is in production it doesn't contain errors, or errors won't occur,
> > is asking for trouble.
>
> As I said earlier, there should be a clear distinction between the kinds
> of errors. Supplying an incorrect DSN is like forgetting a brace: those
> mistakes are made, but once fixed they never turn up again. It's these
> kind of errors I talk about: an application in production state doesn't
> have them, because the application wouldn't run otherwise. Another
> example is that sometimes it's necessary to enforce some kind of method
> calling order: "before calling 'execute()', the method 'initialize()'
> must have been called first." Not judging the design of this code, there
> are various ways to handle this. The execute-method for example could
> check if initialize has been called, and if not do so. But this might
> require an additional internal flag you don't really want. On the other
> hand, in production code, this error can and will never be made. So why
> check for it, slowing down the code?
>
> Also, when some error occurs 'along the line', at what point should it be
> handled? Especially in a library, that should be up to the user of the
> library, and not to the library itself.
>
> That's not to say that databases never go down, but I think those things
> can and should be handled differently.
>
> >> Much of the error handling can be simplified by introducting 'Null'
> >> objects. These are objects of a class that simply do nothing. For
> >> example, you could have a class DB_null that is just like any
> >> DB_common-derived class, and is returned whenever a requested database
> >> class doesn't exists (when calling DB::connect). It simply returns
> >> default values from its methods instead of doing anything useful. This
> >> trick makes using the library a lot easier, and of course it applies to
> >> much more than just the DB class.
> >
> > How would this be better? Rather than return an error, which is what
> > happened, we return a DB Object?
>
> It's better in the sense that the result from a method always has the
> same type. Even if PHP doesn't enforce it, it's very good practice to do
> so anyway.
>
> But I think it would be better if PEAR handled errors altogether
> different.
>
> >
> >> Class DB is the entry point to creating connections to any kind of
> >> database. How many applications need that much abstraction? Not a lot,
> >> I think. That's not to say a class like class DB isn't a good idea, but
> >> I think a programmer should have an choice: either instantiate a class
> >> for any DBMS through class DB, or instantiate a class for a specific
> >> DBMS directly.
> >
> > Your then most likely going to want to use the actual PHP functions for
> > speed improvement anyways.
>
> Of course not. That means I would have to memorize all those
> function-names for all those DBMS's! Another concept of 'reuse' is that
> an interface can be reused. If I write an application on top of MySQL, I
> use a MyDatabase object. If I write one on top of PostgreSQL, I use a
> PgDatabase object. Processing queries and accessing records is much
> easier that way as all methods are the same, and writing code that
> (potentially) works on any database is much easier. If I happen to write
> an application that is not database-specific, I create the necessary
> Database object through a DatabaseFactory. That's an indirection that
> introduces additional overhead, so I only use it if necessary.
>
> >> Class DB_common, like class PEAR, is very large. Too large, if you ask
> >> me.
> >
> > How are you defining too large?
>
> A method is large if it spans more than 20 statements. A class is large if
> it has more than 20 methods. Of course these are all simple rules of
> thumb, but the reasoning behind them (not mine) is sound:
> - When a method has more than 20 lines, it's doing a lot of work and
> probably not a single task. Every method should execute just one task,
> making reuse of that single task possible. A large method should be
> divided into smaller methods so that each method has a single task.
> - When a class has more than 20 methods, it has more than 20 tasks (see
> previous point), which is very likely too much. Classes should be easy to
> understand and have a clear goal. If a class is too large, it can (and
> should) be broken up into smaller classes that do have a clear meaning.
>
> Please note that these points are not mine, nor are they specific for
> PHP.
>
> >> It is very clear that the DB classes are derived from the Perl DB
> >> classes. I find that a shame. Perl was never meant to be used as a
> >> complete programming environment, even though it has grown to become
> >> one. (On I sidenote, I seriously question the mental health of anybody
> >> who uses Perl for more than simple scripting...) I think it's better to
> >> look at programming languages with a good OO design, like Smalltalk or
> >> Java, to see how object-oriented libraries should be written. Learning
> >> OO from Perl is, in my opinion, a bit like learning to ride a bicycle
> >> from someone who has been in a wheelchair his whole life.
> >
> > This is where your PHP inexperience starts to show.
>
> Ouch! :-)
>
> Not trying to sound too arrogant, I think I am an experienced PHP
> programmer. Not only have I been programming a lot in PHP the last couple
> of years (since PHP3), I have been programming in other languages as well
> at the same time (and years before that). These are almost always
> object-oriented languages. I have written fairly large object-oriented
> systems in C++, Java and even Delphi. Maybe I'm not a PHP expert, but I
> certainly am an expert in object-oriented programming, if I may so so
> myself.
>
> As I stated earlier, it's perfectly possible to write very good
> object-oriented programs in PHP. However, OOP is fairly new, so much of
> the code 'out there' is bad. I'm not talking about PHP only here, I also
> include C++, Java, Smalltalk, you name it. Pick a random Java project
> from SourceForge and take a look at the code. Nine out of ten times it's
> very bad.
>
> When people first start to learn OOP, they find it very hard. After a
> while they get used to it, and they think it's actually very easy.
> Unfortunately, that's where most people stop learning. OOP actually IS
> very hard, if you want to do it right. It's like riding a bike: once you
> get the hang of it, it's pretty easy. But that doesn't mean you can
> instantly participate in a marathon and expect to finish with the top 100!
> It requires lots and lots of training to get there.
>
> > Unfortunately, PHP
> > never claimed to be a OO language. Obviously, in ZE2 they are trying to
> > fix that, and a lot of the things you discuss here can be done once it
> > comes out, but right now, technologically, it's not possible.
>
> And that's were I disagree with you (although I do agree that some tricks
> are needed to do it right). On the other hand, I have also been reading
> up on the new features in ZE2, and I'm very anxious to see them done!
>
> Vincent
>
> --
> PEAR General Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PEAR General Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
|
