Re: New configure option for class syntax

>I can't say I like this too much, for various reasons. > >If it's configurable, it means a significantly higher WTF factor when >distributing scripts. Suddenly, IMAP support is not enough - you need to >provide two versions of the script, one which works with standard IMAP, >and another that works with the OO IMAP. > Your right. I hadn't thought of this. Perhaps to fix this we could have an --enable-both option. That way users can use the function based interface and the class based interface, or it can be made a php.ini option. Albeit this further clutters the namespace, however, it would work real nice for creating database independent API's, I mean think of it, changing: $dbh = new MySQL(...); to: $dbh = new mSQL (...); might be all that would be required for changing from MySQL to mSQL. That allows PHP to have database independence in the C API. >Second, I know I may sound like a broken record to many people here, but >PHP isn't an OO language. The OO code isn't too optimized (yet), and I >would avoid pushing people to use it more and more. > I'm not saying or suggesting that this should be implemented right now or even in 4.0.1 or 4.0.5, I'm suggesting that it should be something to change for a major release like say 4.1 or 5.0 (while from now). >Finally, I think that by sticking to the simple rules of prefixing >functions with the proper prefix, this isn't much of an issue. We do need >to avoid adding functions that have no prefix, though. > I agree with the prefixing. However, the idea of using the class interface is completely optional. It wouldn't be enabled by default so its really the choice of the PHP user, if they found it helpful, they could use it. Sterling >On Fri, 9 Jun 2000, Sterling Hughes wrote: > >> I've been contemplating for a while about the issue of PHP's namespace becoming >> more and more polluted as extensions and functions continue to become added. >> I think I have a solution, but at least I'd like to start a discussion on it. >> >> >> Right now PHP has over 1,000 functions if you configure with all the options >> set (unrealistic I know). More functions will be added, more extensions will >> also be added. So what I'm thinking is to add a configure option, something >> like: >> >> ./configure --with-somemodule --enable-class-somemodule >> >> Which would then make that module use PHP's class syntax. Lets take the SWF >> module for example (which has 67 functions): >> >> If you configure: >> >> ./configure --with-swf --enable-class-swf >> >> Then you would access the swf module like so: >> >> $swfStream = new SWF(...); // same arguments as swf_openfile >> $swfStream->ortho (...); // same arguments as swf_ortho >> $swfStream->close (); // same as swf_closefile() >> >> This way, if you wanted, you could have SWF support and save your namespace. >> Ideally every module should be able to support this option, that way users >> don't have to worry about a polluted namespace. >> >> This would also be a more appetisizing syntax to some users for example when >> connecting to a database you could go: >> >> $dbh = new MySQL(…); // Same as mysql_connect >> $sth = $dbh->query ("SELECT * FROM tblname"); //mysql_query >> while ($row = $dbh->fetch_array ($sth)) // mysql_fetch_array >> { >> echo $row["name"]; >> } >> $dbh->free_result($sth); // mysql_free_result >> $dbh->close(); //mysql_close >> >> (Anyone notice that its largely database independent=). What do people think, >> any other ideas, any questions, any elaborations? >> >> Sterling >> >> -- >> PHP Development Mailing List <http://www.php.net/> >> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net >> For additional commands, e-mail: php-dev-help@lists.php.net >> To contact the list administrators, e-mail: php-list-admin@lists.php.net >> > >-- >Zeev Suraski <zeev@zend.com> >http://www.zend.com/ > > >