Comments on: The garbage you can’t dispose of… http://www.sitepoint.com/blogs/2004/05/28/the-garbage-you-cant-dispose-of/ Sun, 07 Sep 2008 21:05:01 +0000 http://wordpress.org/?v=2.5 By: Joshua Eichorn http://www.sitepoint.com/blogs/2004/05/28/the-garbage-you-cant-dispose-of/#comment-407 Joshua Eichorn Wed, 31 Dec 1969 19:00:00 +0000 #comment-407 <p>Thats why no one extends from the PEAR class unless they need destructors. In fact most people try to not even include PEAR.inc until they are actually raising an error.</p> Thats why no one extends from the PEAR class unless they need destructors. In fact most people try to not even include PEAR.inc until they are actually raising an error.

]]> By: CT http://www.sitepoint.com/blogs/2004/05/28/the-garbage-you-cant-dispose-of/#comment-408 CT Wed, 31 Dec 1969 19:00:00 +0000 #comment-408 <p>I have found that it is very easy to code PEAR compatible classes that are a fraction the size of the PEAR ones by only implementing the methods that I use. Like you I only use isError and raiseError. The improved Error class would probably be under 1k. </p> <p>The same with PEAR DB. It is posible to create a class that is under 5k that implements the methods, for a single DB type, used by 90% of PEAR DB users (connect, query, limitQuery, nextId, isError, getMessage and result: fetchRow, numRows, isError, getMessage). Compare that with 34k for DB.php, 30k for DB/mysql.php, and 62k for DB/common.php. The bloat and waste in PEAR is amazing. And lose the wasteful factory pattern. </p> <p>The great things about compatable classes is that other programmers already know the interface and you can always switch back later if necessary. Maybe you WACTies can code up a set of PEAR compatable classes that are not so bloated and wasteful. </p> I have found that it is very easy to code PEAR compatible classes that are a fraction the size of the PEAR ones by only implementing the methods that I use. Like you I only use isError and raiseError. The improved Error class would probably be under 1k.

The same with PEAR DB. It is posible to create a class that is under 5k that implements the methods, for a single DB type, used by 90% of PEAR DB users (connect, query, limitQuery, nextId, isError, getMessage and result: fetchRow, numRows, isError, getMessage). Compare that with 34k for DB.php, 30k for DB/mysql.php, and 62k for DB/common.php. The bloat and waste in PEAR is amazing. And lose the wasteful factory pattern.

The great things about compatable classes is that other programmers already know the interface and you can always switch back later if necessary. Maybe you WACTies can code up a set of PEAR compatable classes that are not so bloated and wasteful.

]]> By: HarryF http://www.sitepoint.com/blogs/2004/05/28/the-garbage-you-cant-dispose-of/#comment-409 HarryF Wed, 31 Dec 1969 19:00:00 +0000 #comment-409 <p>Hi Joshua</p> <p><blockquote><p><br /> Thats why no one extends from the PEAR class unless they need destructors. In fact most people try to not even include PEAR.inc until they are actually raising an error.<br /> </p></blockquote></p> <p>Yes and no. Seems like, for the most part, PEAR developers avoid it but there are a couple of exceptions which are getting widely used, like DB_Common (all the concrete DB implementations extend this) in PEAR::DB and XML_Parser (alot of the XML related packages extend XML_Parser and thereby extend PEAR). Neither of these seems to actually use the destructor functionality.</p> <p><blockquote><p><br /> Maybe you WACTies can code up a set of PEAR compatable classes that are not so bloated and wasteful.<br /> </p></blockquote></p> <p>Problem then is you get into supporting your own version - more work in other words. Generally it's not critical anyway - this is more a special case where it was.</p> Hi Joshua

Thats why no one extends from the PEAR class unless they need destructors. In fact most people try to not even include PEAR.inc until they are actually raising an error.

Yes and no. Seems like, for the most part, PEAR developers avoid it but there are a couple of exceptions which are getting widely used, like DB_Common (all the concrete DB implementations extend this) in PEAR::DB and XML_Parser (alot of the XML related packages extend XML_Parser and thereby extend PEAR). Neither of these seems to actually use the destructor functionality.

Maybe you WACTies can code up a set of PEAR compatable classes that are not so bloated and wasteful.

Problem then is you get into supporting your own version - more work in other words. Generally it’s not critical anyway - this is more a special case where it was.

]]> By: Alan Knowles http://www.sitepoint.com/blogs/2004/05/28/the-garbage-you-cant-dispose-of/#comment-410 Alan Knowles Wed, 31 Dec 1969 19:00:00 +0000 #comment-410 <p>i'm not sure DB_Common is a big issue - you are probably likely to only use 1 instance of it. XML_Parser is a bit more of a nightmare..</p> <p>This is a bug in PEAR - the _PEAR destructor should not be defined.. - hence the array should not be created unless there is a real destructor.... Have you filed a bug :)</p> i’m not sure DB_Common is a big issue - you are probably likely to only use 1 instance of it. XML_Parser is a bit more of a nightmare..

This is a bug in PEAR - the _PEAR destructor should not be defined.. - hence the array should not be created unless there is a real destructor…. Have you filed a bug :)

]]> By: CT http://www.sitepoint.com/blogs/2004/05/28/the-garbage-you-cant-dispose-of/#comment-411 CT Wed, 31 Dec 1969 19:00:00 +0000 #comment-411 <p>"Problem then is you get into supporting your own version - more work in other words. Generally it's not critical anyway - this is more a special case where it was."</p> <p>But Wact did its own DAOs. Why not make them PEAR DB API compatable?</p> <p>"i'm not sure DB_Common is a big issue - you are probably likely to only use 1 instance of it. XML_Parser is a bit more of a nightmare.."</p> <p>They both are. Too many includes; too large includes. Luckily PHP5's PDO and XML will solve both these problems. <br /> </p> “Problem then is you get into supporting your own version - more work in other words. Generally it’s not critical anyway - this is more a special case where it was.”

But Wact did its own DAOs. Why not make them PEAR DB API compatable?

“i’m not sure DB_Common is a big issue - you are probably likely to only use 1 instance of it. XML_Parser is a bit more of a nightmare..”

They both are. Too many includes; too large includes. Luckily PHP5’s PDO and XML will solve both these problems.

]]> By: Lukas http://www.sitepoint.com/blogs/2004/05/28/the-garbage-you-cant-dispose-of/#comment-412 Lukas Wed, 31 Dec 1969 19:00:00 +0000 #comment-412 <p>this bug is fixed now. a reference is now only stored if a PEAR destructor method is defined. So this will only affect those classes that rely on PEAR's destructor emulation.</p> this bug is fixed now. a reference is now only stored if a PEAR destructor method is defined. So this will only affect those classes that rely on PEAR’s destructor emulation.

]]> By: HarryF http://www.sitepoint.com/blogs/2004/05/28/the-garbage-you-cant-dispose-of/#comment-413 HarryF Wed, 31 Dec 1969 19:00:00 +0000 #comment-413 <p>Hi Lukas,</p> <p><blockquote><p><br /> this bug is fixed now. a reference is now only stored if a PEAR destructor method is defined. So this will only affect those classes that rely on PEAR's destructor emulation.<br /> </p></blockquote></p> <p>Many thanks for the info and for fixing it.</p> <p>All the best,</p> <p>Harry</p> Hi Lukas,

this bug is fixed now. a reference is now only stored if a PEAR destructor method is defined. So this will only affect those classes that rely on PEAR’s destructor emulation.

Many thanks for the info and for fixing it.

All the best,

Harry

]]>