Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thursday 03 January 2002 11:08 pm, Zak Greant wrote: Why? Because not everyone wants to use *(#$ing objects in a simple script! No one will be forced to use the wrapper! :) Whilst this is true, and I know that you are thoughtful and conciencious enough to make sure that any new stuff available via OO would also be available via a procedural interface, I fear that this might be the start of a trend which would spoil PHP. If you are a web applications developer, there are plenty of mainstream options if you like OO. There are fewer if you prefer procedural code, and PHP is certainly the natural home for those of us in the latter camp. The further PHP moves into the OO camp, the less appealing it becomes for the procedural people. Once we have an OO interface to such a mainstream extension as mysql (probably *the* most important php extension?), it sends an important message to users and developers alike. Then, a couple of years down the line, PHP is just another OO toy for those who don't like to be in control of their own switch statements :) Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Fri, Jan 04, 2002 at 09:24:33AM +, Phil Driscoll wrote : On Thursday 03 January 2002 11:08 pm, Zak Greant wrote: Why? Because not everyone wants to use *(#$ing objects in a simple script! No one will be forced to use the wrapper! :) Whilst this is true, and I know that you are thoughtful and conciencious enough to make sure that any new stuff available via OO would also be available via a procedural interface, I fear that this might be the start of a trend which would spoil PHP. If you are a web applications developer, there are plenty of mainstream options if you like OO. There are fewer if you prefer procedural code, and PHP is certainly the natural home for those of us in the latter camp. The further PHP moves into the OO camp, the less appealing it becomes for the procedural people. Once we have an OO interface to such a mainstream extension as mysql (probably *the* most important php extension?), it sends an important message to users and developers alike. Maybe you missed that ZE2 new major strength will better OOP support. So its a good idea to start getting users used to it because that is were ZE2 (namespaces, etc) will lead us to. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
At 10:37 AM 1/4/2002 +0100, Markus Fischer wrote: On Fri, Jan 04, 2002 at 09:24:33AM +, Phil Driscoll wrote : On Thursday 03 January 2002 11:08 pm, Zak Greant wrote: Why? Because not everyone wants to use *(#$ing objects in a simple script! No one will be forced to use the wrapper! :) Whilst this is true, and I know that you are thoughtful and conciencious enough to make sure that any new stuff available via OO would also be available via a procedural interface, I fear that this might be the start of a trend which would spoil PHP. If you are a web applications developer, there are plenty of mainstream options if you like OO. There are fewer if you prefer procedural code, and PHP is certainly the natural home for those of us in the latter camp. The further PHP moves into the OO camp, the less appealing it becomes for the procedural people. Once we have an OO interface to such a mainstream extension as mysql (probably *the* most important php extension?), it sends an important message to users and developers alike. Maybe you missed that ZE2 new major strength will better OOP support. So its a good idea to start getting users used to it because that is were ZE2 (namespaces, etc) will lead us to. I don't quite agree. I see PHP's future as a hybrid language which allows most developers to feel comfortable and allows them to use the programming paradigm of their choice. The ease of use which often is very much linked to the functional interfaces is one of the reasons for PHP's success. Although I think it is important to improve the OOP support I am still very much for keeping our functional support as strong as it has been up to today. We are still keeping the OOP support in the Zend Engine 2 at a level which is good for decent OOP developers but aren't going bezerq like OOP fanatics would like us to go :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension
The important thing is to keep at least the same level of functionality for procedural coding This was the entire concern raised about too much OOP form what I gather. There was also the concern raised that your design will be heavily influenced by the possibilities offered by the ZE1, where as the ZE2 will allow many new things that will result in a very different design. Also I do not like how different the API's are in some respects as it is. Further diverging them is nit helping imho. People that want an OOP interface can choose one of the major DB abstraction layers (PEAR DB, Metabase, ADODB ...). Then again Zak's proposal is not about abstraction but about giving an OOP interface and if you are going to do it anyways I guess we can postpone the discussion until the code is there :-) Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Hello, If everybody had _read_ Zak's initial proposal, they should have noticed that he wanted to ADD an OO interface: Create an OO-based wrapper for the MySQL extension. Then there would would not have been an useless and endless thread. My guess that everybody can do more useful things with their time. Derick On Fri, 4 Jan 2002, Lukas Smith wrote: The important thing is to keep at least the same level of functionality for procedural coding This was the entire concern raised about too much OOP form what I gather. There was also the concern raised that your design will be heavily influenced by the possibilities offered by the ZE1, where as the ZE2 will allow many new things that will result in a very different design. Also I do not like how different the API's are in some respects as it is. Further diverging them is nit helping imho. People that want an OOP interface can choose one of the major DB abstraction layers (PEAR DB, Metabase, ADODB ...). Then again Zak's proposal is not about abstraction but about giving an OOP interface and if you are going to do it anyways I guess we can postpone the discussion until the code is there :-) Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Fri, 4 Jan 2002 [EMAIL PROTECTED] wrote: Hello, If everybody had _read_ Zak's initial proposal, they should have noticed that he wanted to ADD an OO interface: Create an OO-based wrapper for the MySQL extension. Then there would would not have been an useless and endless thread. My guess that everybody can do more useful things with their time. Well, you might have the opinion that this an useless thread, but I don't agree. Lukas was very right in saying that the API's would get even more different if this OOP form be added. We will have 2 ways of doing the same thing in MySQL, another set of ways to do the same thing in PostgreSQL (even being similar, there are differences), another completely different way of doing things in OCI and so on. We are talking about keeping the API's as close to each other as possible. One of the things that I like in the Python development is how it is well organized - an official database API exists and module developers stick to it. It doesn't stop just on the DB API, but everywhere on its standard library and built-in functions. Please don't tell me that Python is not PHP - I know that. I just wish things were a little bit more sane in relation to standard APIs across the board. It seems that everywhere people are afraid of trying to set standards, like on the case of PEAR standards or on this case the database related API standard. Don't get me wrong, I don't have any illusion that this will change any time soon (if ever). It is still important to talk about this, and it is definetely not a useless thread to me. Joao Derick On Fri, 4 Jan 2002, Lukas Smith wrote: The important thing is to keep at least the same level of functionality for procedural coding This was the entire concern raised about too much OOP form what I gather. There was also the concern raised that your design will be heavily influenced by the possibilities offered by the ZE1, where as the ZE2 will allow many new things that will result in a very different design. Also I do not like how different the API's are in some respects as it is. Further diverging them is nit helping imho. People that want an OOP interface can choose one of the major DB abstraction layers (PEAR DB, Metabase, ADODB ...). Then again Zak's proposal is not about abstraction but about giving an OOP interface and if you are going to do it anyways I guess we can postpone the discussion until the code is there :-) Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re[2]: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Hi, Create an OO-based wrapper for the MySQL extension. Then there would would not have been an useless and endless thread. My guess that everybody can do more useful things with their time. using OO or a procedural approach to solve a problem is a question of religion (i.e. personal taste). the task of the PHP-developer is to give us both possibilities of which we can choose from. implementing a proper OO functionality in PHP sounds like a good thing and doesn't affect any of the procedural functionality in PHP. this discussion is endless. Kind Regards, Daniel Lorch -- @echo Hello, World; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Proposed updates and extensions to the MySQL extension
Hello All,
Monty has a series of proposed changes and updates to the MySQL extension
(along with a few ideas of mine that we have discussed) that I would like to
present to the dev list for feedback and review.
Synopsis of Proposed Changes
Update the PHP built-in MySQL library to support MySQL 4.0.1
Extend mysql_connect()/mysql_pconnect() to allow the optional selection
of a default database, a MySQL config file and a group within the selected
config file.
The default database parameter will allow the default database to be
selected at connection time, instead of requiring a separate call.
The other parameters will allow the connection to use the client connect
options set in the config file (such as passwords, connection timeouts,
etc.) This will allow passwords to be stored outside of the PHP script.
Allow persistent connections to be closed and 'pruned'. Possible ways to
implement this include adding mysql_pclose(), which would close a
persistent connection and remove it from the connection cache.
...or add a function that flags persistent connections as removeable. Calls
to mysql_close() made on a flagged connection would close it and remove it
from the connection cache. i.e. mysql_trim_pconnections (); An optional
argument could allow the connections to be pruned down to a certain number.
Create an OO-based wrapper for the MySQL extension. The wrapper would
provide the user with access to all of a database's information without
requiring explicit queries or functions calls to retrieve the data. The
user would not need to call call mysql_db_name, mysql_field_*,
mysql_list_fields, etc. The wrapper would also encompass the rest of the
MySQL extension's functionality.
The major benefits of the wrapper would be:
- Small and simple API. The number of functions would drop from 41 to
around 12.
- Full information on the server, databases, tables and fields could
easily be viewed with one call to var_dump()
- Connection handles, etc. would all be managed by the object
- Error messages, last insert id, etc. would be stored as object
properties.
The library would work something like the following:
// Connect to MySQL and select database
$mysql = new oo_mysql ('localhost', 'user', 'password', 'db');
// Accessing the tables property triggers a SHOW TABLES query
var_dump ($mysql-tables);
Notes: The wrapper would not retrieve the information until the
corresponding property was requested. This will keep the size of the object
down.
As always, feedback is welcome! :)
Thanks!
--zak
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Zak Greant wrote: Update the PHP built-in MySQL library to support MySQL 4.0.1 +1 Create an OO-based wrapper for the MySQL extension. Sounds cool :-) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension
This looks really great.
just let us know if you need any help!
James
-Original Message-
From: Zak Greant [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 03, 2002 8:19 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [PHP-DEV] Proposed updates and extensions to the MySQL
extension
Hello All,
Monty has a series of proposed changes and updates to the MySQL extension
(along with a few ideas of mine that we have discussed) that I
would like to
present to the dev list for feedback and review.
Synopsis of Proposed Changes
Update the PHP built-in MySQL library to support MySQL 4.0.1
Extend mysql_connect()/mysql_pconnect() to allow the optional selection
of a default database, a MySQL config file and a group within the selected
config file.
The default database parameter will allow the default database to be
selected at connection time, instead of requiring a separate call.
The other parameters will allow the connection to use the client connect
options set in the config file (such as passwords, connection timeouts,
etc.) This will allow passwords to be stored outside of the PHP script.
Allow persistent connections to be closed and 'pruned'. Possible ways to
implement this include adding mysql_pclose(), which would close a
persistent connection and remove it from the connection cache.
...or add a function that flags persistent connections as
removeable. Calls
to mysql_close() made on a flagged connection would close it and remove it
from the connection cache. i.e. mysql_trim_pconnections (); An optional
argument could allow the connections to be pruned down to a
certain number.
Create an OO-based wrapper for the MySQL extension. The wrapper would
provide the user with access to all of a database's information without
requiring explicit queries or functions calls to retrieve the data. The
user would not need to call call mysql_db_name, mysql_field_*,
mysql_list_fields, etc. The wrapper would also encompass the rest of the
MySQL extension's functionality.
The major benefits of the wrapper would be:
- Small and simple API. The number of functions would drop from 41 to
around 12.
- Full information on the server, databases, tables and fields could
easily be viewed with one call to var_dump()
- Connection handles, etc. would all be managed by the object
- Error messages, last insert id, etc. would be stored as object
properties.
The library would work something like the following:
// Connect to MySQL and select database
$mysql = new oo_mysql ('localhost', 'user', 'password', 'db');
// Accessing the tables property triggers a SHOW TABLES query
var_dump ($mysql-tables);
Notes: The wrapper would not retrieve the information until the
corresponding property was requested. This will keep the size of
the object
down.
As always, feedback is welcome! :)
Thanks!
--zak
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 01:19:03AM -0700, Zak Greant wrote : The major benefits of the wrapper would be: - Small and simple API. The number of functions would drop from 41 to around 12. But you know you just can't remove the existing functions. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On 2002-3-01 02:01, Markus Fischer wrote: On Thu, Jan 03, 2002 at 01:19:03AM -0700, Zak Greant wrote : The major benefits of the wrapper would be: - Small and simple API. The number of functions would drop from 41 to around 12. But you know you just can't remove the existing functions. Of course not!! :) The OO wrapper would not replace the current extension. --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 02:01:16AM -0700, Zak Greant wrote : On 2002-3-01 02:01, Markus Fischer wrote: On Thu, Jan 03, 2002 at 01:19:03AM -0700, Zak Greant wrote : The major benefits of the wrapper would be: - Small and simple API. The number of functions would drop from 41 to around 12. But you know you just can't remove the existing functions. Of course not!! :) The OO wrapper would not replace the current extension. Heh, I feel like an idiot thinking it would be removed. Just not yet woke up, sorry. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Create an OO-based wrapper for the MySQL extension. The wrapper would provide the user with access to all of a database's information without Yeah, lets re-invent PEAR:DB :) Such things are already on the ToDo list for PEAR::DB. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On 2002-3-01 02:43, Alexander Merz wrote: Create an OO-based wrapper for the MySQL extension. The wrapper would provide the user with access to all of a database's information without Yeah, lets re-invent PEAR:DB :) Such things are already on the ToDo list for PEAR::DB. What makes you think that this could not be a part of PEAR::DB? ;) --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Well PHP and MySQL are a very popular combo .. but I do not see a point
in separating the API's even further ... DB API's are a major concern
for myself right now too
It would be really nice to work more in the direction of unifying all of
the API's on a C level
Other than that there is nothing against doing that change .. but I
think it would only make sense to do it across the board
Lukas Smith
[EMAIL PROTECTED]
___
DybNet Internet Solutions GbR
Alt Moabit 89
10559 Berlin
Germany
Tel. : +49 30 83 22 50 00
Fax : +49 30 83 22 50 07
www.dybnet.de [EMAIL PROTECTED]
___
-Original Message-
From: Zak Greant [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 03, 2002 9:19 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [PHP-DEV] Proposed updates and extensions to the MySQL
extension
Hello All,
Monty has a series of proposed changes and updates to the MySQL
extension
(along with a few ideas of mine that we have discussed) that I would
like
to
present to the dev list for feedback and review.
Synopsis of Proposed Changes
Update the PHP built-in MySQL library to support MySQL 4.0.1
Extend mysql_connect()/mysql_pconnect() to allow the optional
selection
of a default database, a MySQL config file and a group within the
selected
config file.
The default database parameter will allow the default database to be
selected at connection time, instead of requiring a separate call.
The other parameters will allow the connection to use the client
connect
options set in the config file (such as passwords, connection
timeouts,
etc.) This will allow passwords to be stored outside of the PHP
script.
Allow persistent connections to be closed and 'pruned'. Possible ways
to
implement this include adding mysql_pclose(), which would close a
persistent connection and remove it from the connection cache.
...or add a function that flags persistent connections as removeable.
Calls
to mysql_close() made on a flagged connection would close it and
remove it
from the connection cache. i.e. mysql_trim_pconnections (); An
optional
argument could allow the connections to be pruned down to a certain
number.
Create an OO-based wrapper for the MySQL extension. The wrapper would
provide the user with access to all of a database's information
without
requiring explicit queries or functions calls to retrieve the data.
The
user would not need to call call mysql_db_name, mysql_field_*,
mysql_list_fields, etc. The wrapper would also encompass the rest of
the
MySQL extension's functionality.
The major benefits of the wrapper would be:
- Small and simple API. The number of functions would drop from 41
to
around 12.
- Full information on the server, databases, tables and fields could
easily be viewed with one call to var_dump()
- Connection handles, etc. would all be managed by the object
- Error messages, last insert id, etc. would be stored as object
properties.
The library would work something like the following:
// Connect to MySQL and select database
$mysql = new oo_mysql ('localhost', 'user', 'password', 'db');
// Accessing the tables property triggers a SHOW TABLES query
var_dump ($mysql-tables);
Notes: The wrapper would not retrieve the information until the
corresponding property was requested. This will keep the size of the
object
down.
As always, feedback is welcome! :)
Thanks!
--zak
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Well yes all (ok molst) of the DB abstraction layers (including Metabase) have an OO style interface and do what should be PHP internal in a perfect world I am hoping that DBX will maybe become the basis for a C based abstraction layer. Here again I would suggest the step by step transition: First implement the basic features and provide a class in PHP that does the rest (was about to suggest a specific layer but I do not want to drag this uptil now unproductive discussion from the pear mailing list here ... so everybody please try to do the same) And then step by step you move more of the complexity into the C layer As such it sounds to me to make more sense on first unifying the API's and doing the OO Wrapping in PHP and once that is working nicely and people have figured out the features they want etc you can go an make a nice OO interface in C Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -Original Message- From: Zak Greant [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 11:41 AM To: Alexander Merz; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension On 2002-3-01 02:43, Alexander Merz wrote: Create an OO-based wrapper for the MySQL extension. The wrapper would provide the user with access to all of a database's information without Yeah, lets re-invent PEAR:DB :) Such things are already on the ToDo list for PEAR::DB. What makes you think that this could not be a part of PEAR::DB? ;) --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On 2002-3-01 03:39, Lukas Smith wrote: Well PHP and MySQL are a very popular combo .. but I do not see a point in separating the API's even further ... DB API's are a major concern for myself right now too It would be really nice to work more in the direction of unifying all of the API's on a C level Other than that there is nothing against doing that change .. but I think it would only make sense to do it across the board I plan to keep my focus on this very small to avoid distraction. :) I am currently working on a PHP based implementation that uses Andrei's overload extension. Once I this is somewhat stable and users have had a chance to work with it, I plan to implement it in C. --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 02:06:23PM +, Phil Driscoll wrote : Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Why? -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, 3 Jan 2002, Zak Greant wrote: On 2002-3-01 03:39, Lukas Smith wrote: Well PHP and MySQL are a very popular combo .. but I do not see a point in separating the API's even further ... DB API's are a major concern for myself right now too It would be really nice to work more in the direction of unifying all of the API's on a C level Other than that there is nothing against doing that change .. but I think it would only make sense to do it across the board I plan to keep my focus on this very small to avoid distraction. :) I am currently working on a PHP based implementation that uses Andrei's overload extension. Once I this is somewhat stable and users have had a chance to work with it, I plan to implement it in C. My personal opinion is that the OOP layer idea is pretty bad. Instead of having 7 or 8 set of functions to learn, now the newbie will have 8 set of functions / APIs. The idea might sound very sexy and everything, but the real problem is that there is already _some_ talks in PEAR-DEV about trying to create a unified API for all databases (a new one, not PEAR::DB) which would be eventually be ported to C. I really don't feel very good with yet another database abstraction package, and this time just for MySQL. I say database abstraction not in the sense that it will abstract everything, but that it gives a thin layer of abstraction to the underlying database. In any case, I _really_ hope you will talk with Stig and get to know more about the latest discussions (flame-wars?) in PEAR-DEV about the upcoming re-write of PEAR::DB and also about the intention of re-writing it in C once it is stable. Joao -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thursday 03 January 2002 2:18 pm, Markus Fischer wrote: On Thu, Jan 03, 2002 at 02:06:23PM +, Phil Driscoll wrote : Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Why? Because I suspect there are plenty of users who either don't know, dislike, or actively hate OO programming. PHP started as a procedural language and currently has OO as a 'bolt on' (I know this will change with ZE2), but it 'feels' mainly procedural. I know that if when I first discovered PHP, if there had been important things it wouldn't let me do without resorting to OO then I would have just continued using C or moved on down the line to find something else. I can't believe I'm the only user in that category. The dev list, of course, will have a disproportionate number of recent(ish) CS graduates who've been through the OO indoctrination classes, so the heated OO discussions here and on the ZE2 list may not impact anywhere near as much as you might think on the average PHP user. Cheers -- Phil Driscoll -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 02:39:02PM +, Phil Driscoll wrote : On Thursday 03 January 2002 2:18 pm, Markus Fischer wrote: On Thu, Jan 03, 2002 at 02:06:23PM +, Phil Driscoll wrote : Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Why? Because I suspect there are plenty of users who either don't know, dislike, or actively hate OO programming. PHP started as a procedural language and currently has OO as a 'bolt on' (I know this will change with ZE2), but it 'feels' mainly procedural. The old API doesn't dissapear, so I see no problem with that. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension
From: Joao Prado Maia [mailto:[EMAIL PROTECTED]] My personal opinion is that the OOP layer idea is pretty bad. Instead of having 7 or 8 set of functions to learn, now the newbie will have 8 set of functions / APIs. The idea might sound very sexy and everything, but the real problem is that there is already _some_ talks in PEAR-DEV about trying to create a unified API for all databases (a new one, not PEAR::DB) which would be eventually be ported to C. yes I second this From: Phil Driscoll [mailto:[EMAIL PROTECTED]] feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Yes I also see a danger there. Procedural is still the method choosen by most newbies and also used a lot of established (php) professionals. So what ever we do, we should always provide atleast the same level of functionality without the OO interface Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 03:49:48PM +0100, Lukas Smith wrote : From: Joao Prado Maia [mailto:[EMAIL PROTECTED]] My personal opinion is that the OOP layer idea is pretty bad. Instead of having 7 or 8 set of functions to learn, now the newbie will have 8 set of functions / APIs. The idea might sound very sexy and everything, but the real problem is that there is already _some_ talks in PEAR-DEV about trying to create a unified API for all databases (a new one, not PEAR::DB) which would be eventually be ported to C. yes I second this From: Phil Driscoll [mailto:[EMAIL PROTECTED]] feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Yes I also see a danger there. Procedural is still the method choosen by most newbies and also used a lot of established (php) professionals. So what ever we do, we should always provide atleast the same level of functionality without the OO interface What tells you that? I see more OO code then procedureal when I browser through misc. sources. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Markus Fischer wrote: Yes I also see a danger there. Procedural is still the method choosen by most newbies and also used a lot of established (php) professionals. So what ever we do, we should always provide atleast the same level of functionality without the OO interface What tells you that? I see more OO code then procedureal when I browser through misc. sources. I host ~30 domains here. I offer PHP to them, carte blanche. Not a single one of them uses classes of any sort except myself. I don't write the scripts, they do. I have done a _lot_ of searching looking for code snippets to learn from in the past year. The vast majority of that code is not OO in nature, instead it is straight-up procedural. PHP is an awesome tool because it allows for both worlds to collide without interfering with each other. It is relatively easy to learn the basic concepts because one is not forced to learn abstracted methods such as object hierarchies just to get a simple (and sometimes not so simple) task done. Let's not break that now. -- Craig Morrison MTS Professional @ http://www.mtsprofessional.com/ A Win32 Email server that works for _you_. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, 3 Jan 2002, Markus Fischer wrote: On Thu, Jan 03, 2002 at 03:49:48PM +0100, Lukas Smith wrote : From: Joao Prado Maia [mailto:[EMAIL PROTECTED]] My personal opinion is that the OOP layer idea is pretty bad. Instead of having 7 or 8 set of functions to learn, now the newbie will have 8 set of functions / APIs. The idea might sound very sexy and everything, but the real problem is that there is already _some_ talks in PEAR-DEV about trying to create a unified API for all databases (a new one, not PEAR::DB) which would be eventually be ported to C. yes I second this From: Phil Driscoll [mailto:[EMAIL PROTECTED]] feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Yes I also see a danger there. Procedural is still the method choosen by most newbies and also used a lot of established (php) professionals. So what ever we do, we should always provide atleast the same level of functionality without the OO interface What tells you that? I see more OO code then procedureal when I browser through misc. sources. The real problem here is not about OOP x Procedural programming, but about duplicating the effort that already began to create a unified database abstraction layer. The PEAR-DEV guys, especially Stig, are working on this for quite a while and it seems very bad to suggest the same work to be started again just because it sounds 'cool'. I repeat once again, why not work with Stig and the rest of the PEAR-DEV guys on this new redesigned PEAR::DB (or whatever it ends up being called) so in the near future we can then think of doing a C port of it ? Joao -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Proposed updates and extensions to the MySQL extension
From: Markus Fischer [mailto:[EMAIL PROTECTED]] What tells you that? I see more OO code then procedureal when I browser through misc. sources. And this code is written by newbies? I am not saying that procedural is the most used method by php experts .. but it is used by php experts (my company for example has a good mix of OO and procedural code with the latter taking up around 65%) I think metabase is a good example of a nice co-existance of OO and procedural since the last release Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
** Reply to note from Markus Fischer [EMAIL PROTECTED] Thu, 3 Jan 2002 15:18:16 +0100 On Thu, Jan 03, 2002 at 02:06:23PM +, Phil Driscoll wrote : Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Why? Because not everyone wants to use *(#$ing objects in a simple script! Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 10:31:51AM -0500, Joao Prado Maia wrote : I repeat once again, why not work with Stig and the rest of the PEAR-DEV guys on this new redesigned PEAR::DB (or whatever it ends up being called) so in the near future we can then think of doing a C port of it ? I appriciate Thomas and Stig's effort very much (and of course all the others which would take too long to list them all). But beside _talking_ about C code I haven't seen anything yet. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 10:35:33AM -0500, Craig Morrison wrote : Let's not break that now. Nothing will be broken. Besides, I encounter classes most of the time when it comes to reuseable components. Why do you think are all things encapsulated in classes in PEAR? And outside (see Manuels repository at upperdesign). -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 01:44:38PM +, [EMAIL PROTECTED] wrote : ** Reply to note from Markus Fischer [EMAIL PROTECTED] Thu, 3 Jan 2002 15:18:16 +0100 On Thu, Jan 03, 2002 at 02:06:23PM +, Phil Driscoll wrote : Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Why? Because not everyone wants to use *(#$ing objects in a simple script! Why? -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, 3 Jan 2002, Markus Fischer wrote: On Thu, Jan 03, 2002 at 10:31:51AM -0500, Joao Prado Maia wrote : I repeat once again, why not work with Stig and the rest of the PEAR-DEV guys on this new redesigned PEAR::DB (or whatever it ends up being called) so in the near future we can then think of doing a C port of it ? I appriciate Thomas and Stig's effort very much (and of course all the others which would take too long to list them all). But beside _talking_ about C code I haven't seen anything yet. So ? I didn't see any C code from Zak either. If all we are doing right now is speculating on the creation of a PHP based 'prototype' of this MySQL-only abstraction thing, why is it more interesting than a existing package like PEAR::DB ? Talk is just that - talk. The weird part is that Zak probably know about PEAR::DB and he might even know about Stig's plan on writing a C port of a stable version of it. Maybe I'm wrong, but I just don't feel very good about all this duplication of efforts and even more about a abstraction class _just_ for MySQL. Joao -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On 2002-3-01 07:32, Joao Prado Maia wrote: [cut] My personal opinion is that the OOP layer idea is pretty bad. Instead of having 7 or 8 set of functions to learn, now the newbie will have 8 set of functions / APIs. The idea might sound very sexy and everything, but the real problem is that there is already _some_ talks in PEAR-DEV about trying to create a unified API for all databases (a new one, not PEAR::DB) which would be eventually be ported to C. I really don't feel very good with yet another database abstraction package, and this time just for MySQL. I say database abstraction not in the sense that it will abstract everything, but that it gives a thin layer of abstraction to the underlying database. In any case, I _really_ hope you will talk with Stig and get to know more about the latest discussions (flame-wars?) in PEAR-DEV about the upcoming re-write of PEAR::DB and also about the intention of re-writing it in C once it is stable. Hi Joao, Thanks for the feedback! I understand your objections, but do not agree with all of them. I am not competing with the PEAR project. I am talking about proposed functionality and have avoided discussions of whether it should be a part of PHP, PEAR/PECL or neither. There is significant work to be done before this would be integrated with anything. No one will be forced to use the wrapper. I am currently focusing on MySQL rather than on all databases. Developing this for a single database reduces the design overhead. The average new user will not need to learn multiple APIs. Initially, they will choose an API that works for them and then learn the bare minimum needed to use it. I am glad that others are discussing similar ideas and would be happy to discuss or collaborate. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On 2002-3-01 07:06, Phil Driscoll wrote: Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. I know that you don't like OO Phil. :) I also dislike (most) OO for many applications. I believe that during this stage, OO is the easiest way to rough this idea out. I will be more than happy to look at a proceedural interface later on. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On Thu, Jan 03, 2002 at 05:43:09PM -0500, Joao Prado Maia wrote : On Thu, 3 Jan 2002, Markus Fischer wrote: On Thu, Jan 03, 2002 at 10:31:51AM -0500, Joao Prado Maia wrote : I repeat once again, why not work with Stig and the rest of the PEAR-DEV guys on this new redesigned PEAR::DB (or whatever it ends up being called) so in the near future we can then think of doing a C port of it ? I appriciate Thomas and Stig's effort very much (and of course all the others which would take too long to list them all). But beside _talking_ about C code I haven't seen anything yet. So ? I didn't see any C code from Zak either. If all we are doing right now is speculating on the creation of a PHP based 'prototype' of this MySQL-only abstraction thing, why is it more interesting than a existing package like PEAR::DB ? Talk is just that - talk. The weird part is that Zak probably know about PEAR::DB and he might even know about Stig's plan on writing a C port of a stable version of it. Maybe I'm wrong, but I just don't feel very good about all this duplication of efforts and even more about a abstraction class _just_ for MySQL. I'll bet my gf that the proposed change to mysql will happen before any PEAR::DB C code has been written. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On 2002-3-01 11:29, Andi Gutmans wrote: Zak, You will probably be better off waiting for the ZE2's new object overloading facilities. It will hopefully be easier to write and will allow you to do some things which you can't do today. If you write it for ZE1 your extension's API might look different than if you had written it for ZE2 due to some existing limitations, changing it later on for ZE2 would then cause a BC problem. Hi Andi, Thanks for the warning! I am partially doing this for practice/fun - as long as we keep the extension away from PEAR/PHP it can be updated to ZE2 when the time comes without breaking BC. :) -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On 2002-3-01 06:44, [EMAIL PROTECTED] wrote: ** Reply to note from Markus Fischer [EMAIL PROTECTED] Thu, 3 Jan 2002 15:18:16 +0100 On Thu, Jan 03, 2002 at 02:06:23PM +, Phil Driscoll wrote : Sounds good to me except for the OO wrappers. Do we already have OO wrappers to anything else not in user land? - if so then I'm probably too late to make the point, but to me such a thing feels 'all wrong' and 'not php'. I'm particularly concerned that we don't create functionality which is only accessible by OO means. Why? Because not everyone wants to use *(#$ing objects in a simple script! No one will be forced to use the wrapper! :) -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
On 2002-3-01 15:43, Joao Prado Maia wrote: So ? I didn't see any C code from Zak either. If all we are doing right now is speculating on the creation of a PHP based 'prototype' of this MySQL-only abstraction thing, why is it more interesting than a existing package like PEAR::DB ? Talk is just that - talk. The weird part is that Zak probably know about PEAR::DB and he might even know about Stig's plan on writing a C port of a stable version of it. Maybe I'm wrong, but I just don't feel very good about all this duplication of efforts and even more about a abstraction class _just_ for MySQL. I do know about PEAR::DB - I looked at the IDEAS file to see what was planned. I probably should have reviewed the PEAR DEV list, but - hey - I can't read every PHP list. I respect the work that the PEAR team has done. Please don't make an issue of something that we do not need to worry about yet. I will keep writing my code. When I have something useable, I will present it to whoever is interested. It can be integrated into PEAR or PHP or nothing -- whatever works best for the users. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
Addressed to: Markus Fischer [EMAIL PROTECTED] [EMAIL PROTECTED] ** Reply to note from Markus Fischer [EMAIL PROTECTED] Thu, 3 Jan 2002 22:00:27 +0100 Because not everyone wants to use *(#$ing objects in a simple script! Why? Count me as one of the people who would not be using PHP if it forced me to always use objects. I think object oriented programming is over-rated, especially the purist version. You know, the people who don't think they can live without private methods and have a heart attack if you directly access a variable in an object. That does not mean that I never use objects, I have a few things in my library where they come in very handy. Mostly as a way of providing a place to store data outside of the global scope, but available to many functions. If you are going to use objects you need to think about them quite a bit before you start coding. After all re-use is supposed to be one of the big reasons for OOP. Sometimes it just isn't worth it. I certainly see no advantage in writing the following program with OOP: ? echo Hello World\n; ? It doesn't make the job easier, and it certainly isn't easier to understand the source code. I don't even see an advantage here: ? include( mysql.plib ); mysql_connect( localhost, username, password ); mysql_select_db( database ); $R1 = Query( SELECT Field1, Field2, Field3 . FROM Table . ORDER BY Field1 ); ? HTML BODY H1Database Dump/H1 TABLE TR THField1/TH THField2/TH THField3/TH /TR ? while( UnpackQuery( $R1 )) : ? TR TD?=$Field1?/TD TD?=$Field2?/TD TD?=$Field3?/TD /TR ? endwhile ? /TABLE /BODY /HTML A lot of web programming doesn't take much more that this. Why make it more complicated by using objects? A few well thought out functions (Query, UnpackQuery) in a library (mysql.plib) can go a long way towards creating simple but robust programs in a lot of cases. Rick Widmer Internet Marketing Specialists http://www.developersdesk.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
