Re: [PHP] PHP vs JAVA
On 8/20/13 9:00 AM, Tedd Sperling wrote: Hi guys: A teacher at my college made the statement that JAVA for Web Development is more popular than PHP. Where can I go to prove this right or wrong -- and/or -- what references do any of you have to support your answer? (sounds like a teacher, huh?) Here are my two references: http://w3techs.com/technologies/details/pl-php/all/all http://w3techs.com/technologies/history_overview/programming_language/ms/y But I do not know how accurate they are. What say you? Cheers, tedd As others have said, he's simply wrong. :-) "Good"ness of either language aside, the data (W3Techs is what I usually cite) is clear: For server-side web dev, PHP is the 800 lb gorilla. For all programming combined? Java may be bigger than PHP, sure. For embedded? No question, Java > PHP as PHP has almost no presence. For "enterprise shops"? There probably are segments of the market that are very Java-centric, even on the web, no question. It's all how you define your scope. I'm sure he could come up with some definition of "market" that would show Java having a bigger marketshare than PHP, within that market. The question is whether that is a valid definition of "market" in context. Lies, damned lies, and statistics. :-) As countering data-points: Wordpress alone is 18% of the web. Drupal is the #1 CMS used to power US government websites. Universities and Museums are very big on Drupal. (That's my day job. ) PHP's marketshare is huge, even in "enterprise". --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] how old is this version of PHP?
Far too much is made of BC breaks between PHP versions. Well-behaved code should still be working a decade later. The catch is that "well behaved" gets tighter each release. For example: $foo = "hello"; $bar = "world"; print $foo[$bar]; In PHP 5.3 and earlier, $bar is a string which makes no sense as an index of a string. It needs to be an int. PHP therefore casts that to an int, gets 0, and you get "h". In PHP 5.4, that was acknowledged as a bug (which it always was), and now triggers a Warning. Because, really, it always was a bug but just failed silently before. Now it tells you so you can fix it. It looks like a BC break, though, because "I get an error I didn't used to". Other things are, eg, removing register_globals and magic_quotes, which have been deprecated for about 12 years and if you were still using them now then your code should break. :-) They're a security hole. But those are very few and far between. --Larry Garfield On 8/19/13 7:25 AM, Jeff Burcher wrote: I apologize if this is off topic, but this raises a question for me. Why can't new versions be backwards compatible? Is it really that difficult to accomplish? This has been a complaint of mine for years with Windows ever since we went from 95 to 98. I am an AS400 programmer and I have legacy programs written in RPG II, which died 20 years ago, and they still run fine on the newest version of AS400 or iSeries or Power System or whatever the heck it is called now. I also have PHP scripts that are many years old that work just fine the way they are, if a new version doesn't come along and make me have to reprogram for no reason just because it can't handle older code. Really, have Do loops and data calls changed that much over the years? I mean, all you do is set a condition, use a variable key field, and voila, data is pulled and processed, no big deal. Yeah, you can get fancy with it, but the core basics are still the same. I have been programming for over 35 years and like to think that once a program is built it should run forever. Do we just accept that we have to rewrite every program we ever wrote every time a new version comes out? A little extreme, but you get my point. Comments? Suggestions? (I am also the kind of guy who thinks quality made hand tools from the 1800s are superior to many purchased today at Lowes or Home Depot.) Thanks, Jeff Burcher - IT Dept Allred Metal Stamping Works "Making Metal Parts since 1946." -Original Message- From: Lester Caine [mailto:les...@lsces.co.uk] Sent: Monday, August 19, 2013 6:24 AM To: php-general@lists.php.net Subject: Re: [PHP] how old is this version of PHP? Larry Garfield wrote: 5.2.9 was released in February of 2009. 5.2 is completely retired and out of support. 5.3 is on security-only life-support. 5.4 is the legacy stable release. Yes, 5.2.9 IS that old. :-) Really, get a host that has made it into this decade. (GoDaddy apparently doesn't meet that qualification.) You're doing clients a disservice by allowing them to run such an ancient and unsupported version. While the statements are correct, many users are not in a position to move from their currently working systems to even 5.3 let alone 5.4. There is still a lot of legacy code that unless a few more people step up and help bring it forward for the many - non programming - users who are stuck with legacy applications, they will remain requiring 5.2 to run. ISPs got caught out when they arbitrarily moved accounts forward, and GoDaddy have even been caught by that, so maintaining a LTS version of PHP5.2 is the lesser evil ... Windows 2000 is supposed to be dead, but *I* still have sites reliant on it because the code and hardware is unsupported in even XP. Saying something is dead only works if there is an affordable way of moving forward ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] how old is this version of PHP?
On 08/17/2013 06:26 PM, Camilo Sperberg wrote: On 16 aug. 2013, at 19:17, Tamara Temple wrote: Looking into a problem for someone who is using Godaddy Shared Web Hosting (I know..), I noticed the version tag reported by phpinfo is: PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Just how old is this version of PHP?? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php According to my google search, it should be 5.2.9, so it isn't "that" old: 5.2.9 was released in February of 2009. 5.2 is completely retired and out of support. 5.3 is on security-only life-support. 5.4 is the legacy stable release. Yes, 5.2.9 IS that old. :-) Really, get a host that has made it into this decade. (GoDaddy apparently doesn't meet that qualification.) You're doing clients a disservice by allowing them to run such an ancient and unsupported version. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
On 7/29/13 3:02 PM, Paul M Foster wrote: On Mon, Jul 29, 2013 at 11:50:01AM -0500, Larry Garfield wrote: On 7/28/13 9:23 PM, Paul M Foster wrote: On Sun, Jul 28, 2013 at 08:46:06PM -0500, Larry Garfield wrote: [snip] Except as noted above. This is all home-grown, using native PHP functions designed to do these things, and classes I've written. I carefully examine each field when writing the POST-handling code with the idea in mind that no matter what the HTML says, the return value must conform to what *I* think it should be. No MVC framework written by others (though I do conform to MVC paradigm). Paul Then you're not writing your own form tags from the sound of it; you're writing your own Form API. Still an improvements. :-) No, I'm writing the form tags as well. I write the whole thing, soup to nuts. But as I'm writing the back end validation stuff, I realize that what I wrote in the HTML doesn't matter when it comes to hackers and script kiddies. So I use my bless and validation libraries to tackle form responses. That's the point I'm making. I understand what you're saying about using someone else's framework so you can make sure that tested code is being used to ensure against hacking attempts. But your pronouncement was so thunderous that I had to provide the exception. If you hang around here and read a book or two on security, you can write your own code that handles this stuff. Particularly if you have an example like CodeIgniter to use, to see how it's done. (There are times when I *don't* write the HTML. My wife the designer does. But I still go in and modify it to provide the validation bits which she can't do. She uses Dreamweaver, so a lot of the time, she doesn't even know what the raw HTML looks like.) Paul So you're writing your own form tags for each specific time you need a form, or you wrote your own form builder API that is writing the form tags for you? Because if the former, I claim it's insecure. The development process is insecure, so you will screw up sooner or later. You're only human. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
On 7/28/13 9:23 PM, Paul M Foster wrote: On Sun, Jul 28, 2013 at 08:46:06PM -0500, Larry Garfield wrote: On 07/28/2013 12:38 PM, Ashley Sheridan wrote: On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote: Never write your own form? I'm guilty - oh, so guilty. What exactly is a 'security hardened' form? - All forms need a valid CSRF token to avoid CSRF attacks. This needs to be matched between the submitted form and server-maintained state. Do all of your forms have that? Every single one? (A GET lookup form like a search box doesn't need it, but anything with POST does, I'd argue.) Yes. I wrote a "bless" class just for this purpose, which I use on all form pages. - Do you have a select element? Do you have error handling for when someone submits a value for that wasn't one of the option elements? Yes, since I realize that what comes back to me may bear no resemblence to what I coded in HTML. Thus, I always check for allowed "SELECT" values. - Your text input field has a max length of 20. Does your code return an error when the user enters a string of 100 characters? Yes. Same answer. Putting a max length of 20 in the HTML works okay, but the user could still submit something much longer if they are attempting to hack the page. Thus I always check for max characters on the return. - Are you checking for weird edge-case-y character encoding issues? (Some versions of some browsers can be hacked by sending UTF-7 instead of UTF-8 for certain parts of the request. I don't fully understand that stuff myself, either.) No I don't check for this. - You have a "number" field (HTML5). Does your PHP code handle someone submitting a string anyway? I don't use HTML5 tags like this, since they are not universally supported. However, I check that numbers look like numbers on return and strings look like strings on return. PHP has built-in functions for this. All this is part of my validation class. - Are you checking all of those correctly every single time you write a form? Except as noted above. This is all home-grown, using native PHP functions designed to do these things, and classes I've written. I carefully examine each field when writing the POST-handling code with the idea in mind that no matter what the HTML says, the return value must conform to what *I* think it should be. No MVC framework written by others (though I do conform to MVC paradigm). Paul Then you're not writing your own form tags from the sound of it; you're writing your own Form API. Still an improvements. :-) Now, let's talk about form accessibility... --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
On 07/28/2013 12:38 PM, Ashley Sheridan wrote: On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote: Never write your own form? I'm guilty - oh, so guilty. What exactly is a 'security hardened' form? - All forms need a valid CSRF token to avoid CSRF attacks. This needs to be matched between the submitted form and server-maintained state. Do all of your forms have that? Every single one? (A GET lookup form like a search box doesn't need it, but anything with POST does, I'd argue.) - Do you have a select element? Do you have error handling for when someone submits a value for that wasn't one of the option elements? - Your text input field has a max length of 20. Does your code return an error when the user enters a string of 100 characters? - Are you checking for weird edge-case-y character encoding issues? (Some versions of some browsers can be hacked by sending UTF-7 instead of UTF-8 for certain parts of the request. I don't fully understand that stuff myself, either.) - You have a "number" field (HTML5). Does your PHP code handle someone submitting a string anyway? - Are you checking all of those correctly every single time you write a form? Remember, a form POST is not a form submission. It's a wide open RPC call for the entire Internet, for which you provide casual suggestions via HTML. Always assume an attacker bypasses the HTML and just POSTs variables right at your server. I'm probably forgetting a few things in the list above, too. Hence, for 98% of cases, if you're writing your own and tags, you're doing it wrong. :-) Maybe you end up with your own PHP library to do that for you that handles all of the above, but... why, when there are so many already that do a better job than you can on your own (because they've had dozens of smart people including security experts working on them)? I would say code forms on your own first, as a learning experience, then use frameworks once you know what you're doing. That I'll agree with. "Do it manually for the learning, then use a battle-hardened tool for real work" is a generally good approach to many things in programming. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
On 07/28/2013 12:14 PM, iccsi wrote: Your name: Your age: In the PHP tutorial manual, it says that we can have post action to the form itself just like above coding.I would like to know in the real projects, can we have action to the same PHP file, since that we only need have one filebut not 2 files foe POST request,Your help and information is great appreciated,regards,Iccsi, "Real" projects to all kinds of things. Which is best depends on who you ask. :-) I would argue that there's 3 "good" approaches, both of which are viable: 1) Define your form abstractly via an API, and have the API detect the presence of POST request and then process the form after it's built. That means you do submit back to the same URL. (Drupal 7 and earlier do this.) 2) Put 2 separate request handlers / controllers at the same path, one for GET and one for POST. So you submit back to the same URL but an entirely different piece of code responds to it. (This requires a good routing system that can differentiate between GET and POST.) 3) Every form is defined as its own object somewhere with a unique ID. All forms post to the same URL but include the form ID. Code at that URL looks up the form object by ID and maps the submitted data to it to know what to do with it. Note that in all 3 cases you're defining a form via an API of some kind. You are not writing form tags yourself. Don't do that. Ever. I promise you that you will have a security hole or six if you do. Use a good form handling API for building forms. That's what good "Real" projects do. There are a lot out there. Most fullstack frameworks or CMSes have one built in (I know Drupal and Code Ignighter do, although they're quite different), and there are reasonably stand-alone components available in both Symfony2 Components and Zend Framework. Please don't write your own. There are too many good ones (and even more bad ones, of course) already out there that have been security hardened. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Split/Group date together.
If I understand you correctly, I call what you're trying to do "PHP group by", and did a write up on it a few years back: http://www.garfieldtech.com/blog/php-group-by-with-arrays --Larry Garfield On 7/18/13 8:43 AM, Karl-Arne Gjersøyen wrote: Hello again. In my program I have this: mysql> SELECT * FROM transportdokument WHERE dato >= '16/7/2013' AND dato <= '18/7/2013'; This list all reccrds for 3 days. I need a way to split it up for every day even when the requst is as above and don't know in what way I can do it. I like to have all records for day 16 in one table in PHP/HTML and all records for day 17 in another table. i.e, Day 16 have 5 rows and day 17th and 18th have 7 and 8 rows. I hope for your help and advice to do also this correct. Thank you for your time and effort! Karl -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] json stream filter
On 06/20/2013 04:26 AM, Markus Staab wrote: Hi! first post on the list, so please bare with me ;-) we are handling a lot of cache files in our apps and use json to persist those contents on the filesystem, because it seems to be the fastest possible way to read/write files with PHP. Since I discovered stream-filters, http://www.php.net/manual/en/filters.php, we use those also for base64 encoding files before sending them over the wire, which preserves a lot of memory and allows even bigger files. Would it make sense to also have a native stream filter for fileformats like JSON, to get maximum performance for reading/writing those (and also to be able to write big files)? Thanks, Markus What would it do, exactly? Stream filters still have to read/write a string, don't they? Unless you're talking about reading directly into a nested array structure (what json_decode() does), I am not sure what the benefit is of what you're describing. (And I'm not sure you could do that, although it would be neato if you could.) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A Good OOP Tutorial/Read?
On 05/16/2013 06:45 PM, Tedd Sperling wrote: Thanks to both Bastien and Sebastian: While I understand that an interface is like an abstract Class, in that you don't have to flesh-out your methods, but rather where you define exactly how Classes who implement that interface will be required to flesh-out those methods. But so what? What's the point? Without giving me complicated examples, just give me one simple example that illustrates the advantage of using an interface over writing a new Class where you flesh-out whatever methods you want. After all, an interface requires the same thing, does it not? As such, I just don't see the advantage interfaces bring. Cheers, tedd Practical example, PSR-3: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md Say you're writing a stand-alone library, maybe a Twitter-connecting library. You want to be able to log stuff, but don't want to have to deal with opening log files yourself. You also want to allow your library to be used by people running Symfony, Code Igniter, Drupal, Zend Framework, or PHPBB, all of which have their own logging systems in place that may talk to syslog, a database, files on disk, or whatever. People using those frameworks don't want your library spewing log files all over their file system. Instead, you simply support the PSR-3 logging interface. You accept an object that implements that interface in your constructor, and then write to it. What happens on the other side? Who gives a damn! For your own testing, you can write a simple class that implements that interface and dumps log messages to disk. When someone uses your library with Symfony, they just pass in a Monolog object (the logging system used by Symfony), and your code is now logging errors to whatever they have Monolog configured to do. When someone uses your library with Drupal, they just pass in the Drupal Watchog logger object (which is being rewritten to use PSR-3 as we speak), and now your library is logging errors to Drupal's logging system (which could be syslog or a DB table, depending on how the user has their site configured). And you don't give a damn about any of that. All you care about is that you support "any object that matches this interface". What that object does with the messages you send it, and where that object came from, you don't have to give a crap about. Now take that same concept and apply it at a smaller scale, within your own project. Swap out your database-based cache system for a memcache-based one. Your code doesn't change, because it's writing to an interface, not to the database. Swap out your data store with one that is used just for testing. Etc. That's what interfaces give you. Loose coupling, and the ability to divide-and-conquer... and even let someone else solve problems for you. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: [PHP-DEV] feature request : easy shared memory
On 03/14/2013 01:21 PM, Bob Weinand wrote: Sharing active memory between processes goes against the "shared nothing" design of PHP. The lack of the feature you're describing is itself a feature. :-) If you had real shared memory, then you're now writing a multi-threaded app. Even if you aren't using threads per se it's the same level of potential for spooky action at a distance. If your problem space really requires that (and there certainly are those that do), Java or NodeJs will suit you better because those are built specifically for a persistent-server model, rather than PHP's shared-nothing design. However, in practice most PHP/web applications don't need that, because HTTP is a stateless request/response system. Shared-nothing more closely models what the actual environment is doing, and can still be very performant as long as you don't do anything naive. If you're doing something stateful like Web Sockets, then you can run PHP as a cli application that is its own persistent server rather than as an Apache add-on. For that, look at Ratchet: http://socketo.me/ --Larry Garfield If PHP should be so restrictive against sharing, why are there extensions like memcached, ...? Someone must have missed this possibility to share rapidly... If I need something like websockets, I use the pthreads extension: perfectly suited for stateful applications. For example: I want to have the database in memory (no, no mysql Memory-tables; this is too slow...) and only do the updates into the database for faster access when most contents are read-only. What are these good reasons against such a feature except it violates the shares-nothing superlative of PHP. (Even if this feature would exist, you can still write PHP without sharing) Bo Weinand Memcache is out of process. There are possible race conditions there, but FAR fewer and FAR more contained than true multi-threaded environments. This list has debated the merits of shared-nothing many times before; it was a deliberate design decision in the interest of simplifying development for the overwhelming majority of users. If your app is so performance sensitive that a memcache lookup is going to bring it to its knees, then either you're misusing PHP or you're better off using something other than PHP. (PHP is not the tool for every use case.) In any event, adding true shared memory to PHP would be nearly impossible without completely redesigning the way it interacts with web servers. The alternative is to write your own PHP CLI application that connects to sockets itself and runs as a daemon (possibly using the pthreads extention as you mention), and cut apache/nginx out of the picture entirely. If your use case calls for that, knock yourself out. But the "good reasons" against adding such a feature is that it would require rewriting everything and rearchitecting the entire Apache SAPI, which is not happening any time soon. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] UNLESS Statement Equivalent
On 3/11/13 6:25 PM, Angela Barone wrote:
On Mar 11, 2013, at 4:10 PM, Jonathan Sundquist wrote:
the variable $current_page does not exist.
That was my problem. :( I've been staring at this for too long. Too
bad there's not a 'use strict' pragma.
There is. Always set your development environment to E_ALL | E_STRICT,
and it will yell at you about every little thing, including undefined
variables.
http://php.net/manual/en/function.error-reporting.php
I would also suggest keeping with your original statement to return early and
return often. Its best to exit out of your functions sooner than later.
Specially if its a large function.
O.K. I just thought there might be a more elegant way of doing it. I
at least got rid of the else statement like you mentioned.
Thanks for your help,
Angela
If you find yourself with a function that's too long and complex from
the if-statements, your first step is to break it up into utility functions.
if (...) {
// Something Long
}
else {
// Something Else Long
}
Becomes:
if (...) {
something_long();
}
else {
something_else_long();
}
function something_long() {
}
function something_else_long() {
}
That helps both readability and testability.
Also, on your original boolean question, note that negation is
distributive. That is:
!($a && $b && $c)
is the same as:
!$a || !$b || $!c
Which means that if your checks are all equality checks, as in your
case, you can simply do:
if ($a != 'a' || $b != 'b' || $c >= 'c') {
}
Which may be easier to read. If those checks are not trivial then
there's also a micro-performance benefit there, as the first statement
that evaluates to true will cause the whole thing to return true, so the
second and third options don't need to be evaluated.
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] static Logging class?
Make a real classed object that you pass to various objects that need it. Otherwise you make your life way harder for unit testing. Don't have a class that self-enforces that it's a singleton. That way lies pain. In particular, I recommend using or writing a class based on the PSR-3 recommendation: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md There's even stock code for the interface and some useful base classes available: https://packagist.org/packages/psr/log And for added fun, there are already publicly available open source libraries that implement PSR-3 that you can just drop in and use, such as: https://packagist.org/packages/monolog/monolog (If that's too heavy for you, writing your own PSR-3 compatible logger is dead-simple.) I'm sure you're about to say "zOMG this is just a hobby project, I don't need something that fancy and all injected and shit!" If it's a simple project, use a simple container to do all the hard work for you: https://packagist.org/packages/pimple/pimple (That's < 100 lines of executable code. Quite powerful, dead simple to use.) Cheers. --Larry Garfield, FIG member On 03/03/2013 07:26 AM, Lars Nielsen wrote: Hi, I work on a little hobby-project, and i want to make a oo logging facility. (php5.3 oop) Is it best to make a class with static functions that i can call from my other classes? Or is it more appropriate to make a real logging-class i should instantiate every time i need to log something? (I just want to log to a file) Best regards Lars Nielsen -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Lucene library
Ah ha. Did that ever get ported to Zend 2? --Larry Garfield On 12/12/12 12:07 AM, Louis Huppenbauer wrote: There's Zend_Search_Lucene, part of the Zend framework. I think it should be possible to use it without the whole framework though. http://framework.zend.com/manual/1.12/de/zend.search.lucene.html 2012/12/12 Larry Garfield Yes, I've worked with Apache Solr quite a bit. It's a separate server, however, and I'm looking for something with smaller requirements for a concept I want to try. I'd consider SQLite, but I really need something schema-free and PHP-native/easily-installable. --Larry Garfield On 12/11/2012 07:20 PM, israele...@gmail.com wrote: Check out apache solr. The php implementation of Lucene was very slow and had a lot of perfomance issues the last time I tried it --Original Message-- From: Larry Garfield To: php-general@lists.php.net Subject: [PHP] Lucene library Sent: Dec 11, 2012 5:41 PM Hi all. I recall hearing about there being a PHP port of the Lucene library some years ago, but I don't recall whence it came. It was a stand-alone PHP lib, which needed some integration to be viable as an actual search engine but worked up to a point by storing data straight on disk as files. That meant it didn't scale beyond a few tens of thousands of records, but that's still a decent number. Does that ring a bell for anyone? Anyone know if it still exists, and if so where? I didn't find it in https://packagist.org/ , which is where I figured it would be if it were still maintained. I may have a use for it if it still exists. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Lucene library
Yes, I've worked with Apache Solr quite a bit. It's a separate server, however, and I'm looking for something with smaller requirements for a concept I want to try. I'd consider SQLite, but I really need something schema-free and PHP-native/easily-installable. --Larry Garfield On 12/11/2012 07:20 PM, israele...@gmail.com wrote: Check out apache solr. The php implementation of Lucene was very slow and had a lot of perfomance issues the last time I tried it --Original Message-- From: Larry Garfield To: php-general@lists.php.net Subject: [PHP] Lucene library Sent: Dec 11, 2012 5:41 PM Hi all. I recall hearing about there being a PHP port of the Lucene library some years ago, but I don't recall whence it came. It was a stand-alone PHP lib, which needed some integration to be viable as an actual search engine but worked up to a point by storing data straight on disk as files. That meant it didn't scale beyond a few tens of thousands of records, but that's still a decent number. Does that ring a bell for anyone? Anyone know if it still exists, and if so where? I didn't find it in https://packagist.org/ , which is where I figured it would be if it were still maintained. I may have a use for it if it still exists. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Lucene library
Hi all. I recall hearing about there being a PHP port of the Lucene library some years ago, but I don't recall whence it came. It was a stand-alone PHP lib, which needed some integration to be viable as an actual search engine but worked up to a point by storing data straight on disk as files. That meant it didn't scale beyond a few tens of thousands of records, but that's still a decent number. Does that ring a bell for anyone? Anyone know if it still exists, and if so where? I didn't find it in https://packagist.org/ , which is where I figured it would be if it were still maintained. I may have a use for it if it still exists. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multithreading for OOP PHP
On 10/31/12 1:58 AM, Florian Müller wrote: Hi guys I was wondering, what actually the reason is that PHP itself does not support multi-threading? I guess this would be realizable, or not? If not, why? Maybe this is a stupid question, but still somehow interesting. Realization in a way as Java does (or just something in that way) would actually be a very nice thing, don't you think? Thank you for your answers :) Florian PHP is by design a shared-nothing architecture. What's happening in one process/request cannot impact what's in another request. They may both write out to the same external service (DB, memcache, etc.), but they do not interact. That makes the program much much simpler, since you don't need to worry about state synchronization. It also means you can scale up by just adding more servers, because you don't need to deal with "oh, now the memory isn't shared, so now what do I do?" Each PHP process could be in its own CPU core, CPU, server, or server cluster, and the code doesn't change in the slightest. The "shared nothing" architecture is a very deliberate design decision, and is in a large part responsible for PHP's success. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] foreach
On 10/17/12 10:17 AM, Matijn Woudt wrote:
On Wed, Oct 17, 2012 at 1:25 AM, Larry Garfield wrote:
For the love of god, please stop using ext/mysql (aka the mysql_*
functions). It's insecure and slow and lacks features.
Instead, use PDO, and bind your parameters. As a nice bonus, the result
from a PDO-based query is not a raw resource but an iteratable object, which
means you can foreach() it.
http://php.net/manual/en/book.pdo.php
$conn = new PDO(...);
$result = $conn->query("SELECT * FROM items");
foreach ($result as $record) {
// Do something with each record here.
}
--Larry Garfield
Yes, the mysql extension is deprecated, but what's wrong with mysqli?
mysqli has the advantage that you don't need to keep a database handle
floating around, but you can just use mysqli_query everywhere.
When having multiple files and classes, it's terrible to pass $db to
each function/class, and I hate to use the global keyword.
just use while($record = $result->fetch_array()) instead of
foreach($result as $record)
And you mention ext/mysql is slow, well don't know about that, but PDO
is a bit slower than mysqli atleast.
I quote from [1]:
"For inserts, there was no significant difference between MySQLi and
PDO (prepared statements or not). For selects, MySQLi was about 2.5%
faster for non-prepared statements and about 6.7% faster for prepared
statements. "
- Matijn
[1] http://jnrbsn.com/2010/06/mysqli-vs-pdo-benchmarks
Nothing is wrong with mysqli per se. It's up to date and secure, and
certainly better than ext/mysql. I recommend PDO over mysqli because:
1) PHP-engine-level global state (ie, not specifying a connection) is
the source of most (although not quite all) evil. Really, that way lies
pain once you get into anything reasonably complicated and want to be
able to test it properly.
2) PDO is installed by default on virtually every PHP system in the
world. ext/mysqli has never been part of the default build of PHP, and
many to most web hosts don't have it installed.
3) mysqli's API is a bizarre hybrid of procedural and OO that confuses
the heck out of me. PDO's is far from perfect, but is more consistent
and cleanly OO from the get-go.
I skipped mysqli entirely and went straight to PDO when it became available.
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] foreach
On 10/15/12 9:05 PM, David McGlone wrote:
On Monday, October 15, 2012 08:21:23 PM you wrote:
Bastien Koert
On 2012-10-15, at 8:16 PM, David McGlone wrote:
I've been sitting here playing around with foreach() and I'm wondering why
I am getting these results. here's what I've been fooling around with.
the code has no perticular meaning, but I noticed if the script fails, I
get the sentence "Too expensive I'm going home LOL" 6 times because there
are 6 words in the sentence. I also have a database that looks like this:
product_idproductprice
1Milk2.59
2bread1.05
And when $row is equal to 0 the output I get is
1 1 Milk Milk 2.59 2.59 Which is printed to the screen according to how
many rows are in the db I belive.
So my question is why this behavior? I was expecting something like a
while
loop.
Dave,
Foreach is an iterator over an array. Your $row is a pointer to a db result
set. If you were to pass the $row result set to the foreach as an array,
you'd get what you think you should
Www.php.net/foreach
Thanks Bastien.
Heres what I started with:
$result = mysql_query("SELECT * FROM items");
$row = mysql_fetch_array($result);
foreach($row as $rows){
$row = 0;
if($row == 0){
echo $rows;
} else{
echo "Too expensive I'm going home LOL";
}
}
Here's what I ended up with after you gave me the advise:
$result = mysql_query("SELECT * FROM items");
$rows = array();
while($row = mysql_fetch_array($result))
$rows[] = $row;
foreach($rows as $row){
$product = $row['product'];
$price = $row['price'];
echo "$product ";
echo "$price ";
$justright = 0;
$toohigh = 5; //I was going to use this to check if the price was too high
just so I could use an elseif in the exercise,
but I realized that
it would only work if the if() evaluated to
false, which would be
impossible. Ahhh pizz on it, it was fun anyway!
:-)
if($justright <= $price){
echo "Not bad. I'll buy it.";
} else
echo "Too expensive I'm going home LOL ";
}
For the love of god, please stop using ext/mysql (aka the mysql_*
functions). It's insecure and slow and lacks features.
Instead, use PDO, and bind your parameters. As a nice bonus, the result
from a PDO-based query is not a raw resource but an iteratable object,
which means you can foreach() it.
http://php.net/manual/en/book.pdo.php
$conn = new PDO(...);
$result = $conn->query("SELECT * FROM items");
foreach ($result as $record) {
// Do something with each record here.
}
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The end of "mysql"
And I didn't see the follow-up messages saying that they do support PDO after all. Crisis averted! :-) I have actually found very few hosts that run ext/mysqli. Everyone I know jumped from ext/mysql to PDO. I've never actually run mysqli myself; at this point everything I do is PDO. --Larry Garfield On 09/09/2012 04:49 PM, Larry Garfield wrote: Then get a new host. A host that disables PDO these days is a host that deserves to go bankrupt. ext/mysql has been dead for years now. --Larry Garfield On 09/08/2012 08:54 AM, Jim Giner wrote: Nope. No PDO as yet either jg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] The end of "mysql"
Then get a new host. A host that disables PDO these days is a host that deserves to go bankrupt. ext/mysql has been dead for years now. --Larry Garfield On 09/08/2012 08:54 AM, Jim Giner wrote: Nope. No PDO as yet either jg On Sep 7, 2012, at 11:22 PM, Adam Richardson wrote: On Fri, Sep 7, 2012 at 9:58 PM, Jim Giner wrote: So with the announced end of the mysql functions (and switching to a different extension), one would think that my isp/hoster would be a bit more interested in my dilemma. I tried today to create my first mysqli-based test script and found that I didn't have that extension. A series of emails with my tech support told me that the shared server farm does not get "mysqli" - only their business servers. Since I dont' have a need for and want to pay more for a 'business server', I'm told I'm s... outta luck. What about PDO? Is that available? Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OT (maybe not): Drupal vs WordPress
On 8/20/12 3:36 AM, Simon Schick wrote: One thing I also really like at the TYPO3-philolsophy: If someone finds a security-issue he should immediately get in contact with the developers (of the extension and the TYPO3 security team) and discuss the issue with them. They decide how critical the bug is and will do a hard work to get the fix as soon as possible. If it is a very critical issue (someone could gain admin-access by something) they will send out an email that there will be a bugfix coming out at next-coming day at 9 o'clock GMT and everyone is advised to update his TYPO3-core or the extension. This is something I really like! To be prepared for some critical fix and knowing that (in a perfect case) no-one should have heard about that issue before who wants to hack my website :) Don't know if there's some similar security-policy in other communities than this :) Drupal's security process is substantially similar, and also follows security best practices: http://drupal.org/security-team --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OT (maybe not): Drupal vs WordPress
Only semi-joking line that's been making the rounds lately: If you want to build a blog, use Wordpress. If you want to build Wordpress, use Drupal. If you want to build Drupal, use Symfony2. There is much wisdom in those lines. --Larry Garfield, an openly biased Drupal core developer On 8/19/12 2:52 PM, l...@afan.net wrote: Hi to everyone, I was trying to figure this out for the last week or two. I have read tons of articles that compare Drupal and WordPress, but I still wasn't swayed to either side. I know that they are both good, both do the job well, and both have advantages and disadvantages. For example, Drupal has a steeper learning curve, but you get more control over the website. Most of Drupal vs WordPress articles are "emotionally" driven and it reminds me of the PC vs Apple flame war. I was trying to exclude these as much as I could but it's hard. Is there any website/article/benchmark/test/experiment/whatever I can trust to be unbiased? I need a website that measures the CMS' through facts, not heated, emotional arguments. In which cases is it better to use Drupal over WordPress (and vice-versa)? I know the first two words are going to be "it depends", but let's talk about it in general (for small basic websites, more complex websites, easy customization, etc). I found this on one page: "... Drupal was built as a fine-grained multi-role system where you can assign different permissions to different roles to do different things (e.g. content editor, content reviewer, member, etc.) and assign users to these roles..." Does that mean that WordPress can't do that? Maybe it can, and the quotation is true, but it is kind of misleading to say that one of the programs does something, and then not mention the other product at all. Special points for me are (not a must, though) - multiple websites with single core (both CMSs have the capability but I got impression Drupal does it better?) because of maintenance - compatibility with CiviCRM Once I decide what to use, I have to stick with it for a while. Thanks for any help. LAMP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] What's the best way to make a dynamic plugin architecture?
On 8/27/12 6:11 PM, Matijn Woudt wrote: You should never be calling require() yourself. Just follow the PSR-0 naming standard and use an autoloader, then you don't have to even think about it. There are many existing autoloaders you can use, including Composer's, Symfony2's, and probably Zend has one as well. I believe there's one in PHP by default now called SPLClassLoader or something like that.. - Matijn There was a proposal for one, but it was never added. You still need a user-space class loader for PSR-0, but they're readily available. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] What's the best way to make a dynamic plugin architecture?
On 8/27/12 4:09 PM, Mark wrote:
On Mon, Aug 27, 2012 at 4:26 PM, Stuart Dallas wrote:
2. Let the plugin itself (so in this case PluginOne.php) open itself
and register it to the PluginLoader.
With the first option i have to do eval which i try to avoid if possible.
With the second solution the PluginLoader probably has to be a singlethon.
Why does it need to be a singleton?
Well, i would then do something like this from within the included
plugin file after the class:
PluginLoader::getInstance()->registerPlugin(new PluginOne());
Or something alike.
I'm not sure I see what PluginLoader is doing? It makes more sense to me if you
register like so:
PluginLoader::getInstance()->registerPlugin('PluginOne');
Then you get an instance of the plugin:
$plugin = PluginLoader::getInstance()->factory('PluginOne');
Tho, even then I don't see what the PluginLoader is adding to the party.
Well, i'm making the classes up as i type. I don't actually have a
PluginLoader yet. Or rather, i'm just beginning to make it right now.
What it's doing is very simple. Read through the directory of the
plugins and load every single plugin it finds in memory. Then every
plugin registers the mime types it can handle. That information is
stored in the PluginLoader upon which some other place can call:
PluginLoader::pluginForMime("text/html"). Though i still have to take
a good look at that.
But you're right, i can use the factory pattern here.
Ahh, I see. Personally I'd go with the following (pseudocode)...
Inside the PluginLoader constructor (or other method)
foreach (plugindir)
require plugindir/plugindir.php
$plugindir::init($this)
The static init() method calls PluginLoader::registerPlugin('mime/type',
'PluginClassName'). Then pluginForMime does a lookup for the mime type and
returns an object of the corresponding type. That way a single plugin can
support multiple mime types.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
That sounds sane and i probably go for that :)
Thanks for clarifying it a little.
You should never be calling require() yourself. Just follow the PSR-0
naming standard and use an autoloader, then you don't have to even think
about it. There are many existing autoloaders you can use, including
Composer's, Symfony2's, and probably Zend has one as well.
Also, the key question is how you'll be mapping your situation to the
plugin you need. If it's fairly hard-coded (i.e., "mime type of foo =>
class Bar"), then just use a simple dependency injection container like
Pimple. If it's more complex and situational, then yes a factory is the
easiest approach.
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: [PHP-WEBMASTER] Re: [PHP] The Cat Signal
Sales tax isn't the point with SOPA/PIPA. Thinks like the government being able to force any site off the Internet at the ISP / DNS level on the say-so of a private corporation are the point. And no, that's not a defensible or acceptable position. Breaking the Internet to prop up industries that don't like being disrupted is not a proper use of governmental power. I'm quite happy to see PHP.net joining in with other defense-of-freedom voices. --Larry Garfield On 7/21/12 1:56 PM, With No Name wrote: On Fri, July 20, 2012 10:04, Lester Caine wrote: In Europe VAT is applied even on on-line sales. It is the likes of Amazon shipping bulk stock from overseas 'clients' into European warehouses and then supplying them without VAT added directly in Europe that is the problem! How can I compete with someone who is also giving next day delivery, but 20% cheaper ... American sellers are one of the problems here. It depends, because in Europe (I live in Germany), VAT is only added if the value + shiping exceeds 25 Euro and customs are only added, if the value exceeds 150 Euro It does NOT discriminate American sellers, because German sellers have to bill the VAT too Also I buy regulary in the USA and even with heavy USPS costs plus Import-VAT I am mostly lesser expensive as if I buy in Germany... Greetings -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php batch/queue framwork
On 06/29/2012 05:18 AM, Tom Sparks wrote: Forwarded Message: php-general_318334.ezm Re: php batch/queue framwork Friday, 29 June, 2012 6:30 AM From: "Shailesh N. Humbad" To: php-general@lists.php.net On 6/28/2012 11:58 AM, Tom Sparks wrote: I am looking for a batch/queue framework that is database-centric? I could write my own, but I want one that is mature tom_a_sparks "It's a nerdy thing I like to do" You could try Amazon Simple Queue Service: http://aws.amazon.com/sqs/ Use the PHP SDK: http://aws.amazon.com/sdkforphp/ I was hoping for something that I could run local on my host tom Have a look at Beanstalk and Gearman. They're the most common run-yourself queues I've seen, and both have PHP libraries available. ZeroMQ is also the darling of the queuing world these days, but I don't know off hand how good the PHP support is. You won't find a GOOD "database-centric" queue framework, rather by definition. A queuing server may use a DB of some kind as a backend itself, but a queue server by definition pushes tasks to workers that are waiting for it. That's simply not how an SQL DB is designed. You would have to do a polling worker that polls a database for new tasks. You could write such a system -- Drupal comes with one as a default implementation since then you don't need a separate queueing program, for instance -- but it will always be greatly inferior to a real daemonized queue server. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] code deployment through php
On 5/1/12 4:19 AM, rene7705 wrote: On Tue, May 1, 2012 at 11:11 AM, Camilo Sperberg wrote: If I understood the problem correctly, you want to keep a single copy of your code on every machine you work, including the final server. Well, I want to work on 1 copy of my common code on my windows machine, then sync those changes to all my sites (hosted on the win dev box) to see if it messes up the other sites, then FTP those changes to my hosting account, and run the sync script there as well. Have you read about SVN ? You can set up a cronjob to execute it automatically if you want, there are clients for Windows, Zend Studio, etc etc. I've read about some source control systems, I've tried them out, but I'd rather go for this simpler approach tbh. I already do regular backups that are timestamped, it's enough for me right now I think. No it's not. Really. For what you describe, a proper version control system is the correct tool. Rolling your own with rsync and cron is setting yourself up for failure. A couple people here have mentioned SVN. I used to use SVN, but now have migrated everything I do to Git. Without getting into a religious battle between Git and SVN, I do strongly recommend you look into it. This is an excellent resource for why to use it and how to use it: http://progit.org/book If you're serious about development, get serious about version control. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] To ?> or not to ?>
On 4/4/12 12:14 AM, Donovan Brooke wrote: Robert Cummings wrote: [snip] Could using ob_start and ob_end_flush eliminate the ambiguity of whether or not to use '?>'? In the generally recommended case of don't use them at the end of your file... where's the ambiguity? http://www.php.net/manual/en/function.include.php http://www.php.net/manual/en/language.basic-syntax.phpmode.php Those seem to suggest to use them... thus the ambiguity. Donovan Most major projects at this point leave it off, and their coding standards say to as well. The official PHP docs are generally non-commital by design, but outside of those I think it's pretty well-established to just leave it off and be happy. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Arrays: Comma at end?
On 2/7/12 1:50 PM, Micky Hulse wrote: Was there ever a time when having a comma at the end of the last array element was not acceptable in PHP? I just did a few quick tests: <https://gist.github.com/1761490> ... and it looks like having that comma ain't no big deal. I can't believe that I always thought that having the trailing comma was a no-no in PHP (maybe I picked that up from my C++ classes in college? I just don't remember where I picked up this (bad) habit). I would prefer to have the trailing comma... I just can't believe I have avoided using it for all these years. Thanks! Micky Drupal's coding standards encourage the extra trailing comma on multi-line arrays, for all the readability and editability benefits that others have mentioned. We have for years. Cool stuff. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] news and article posts in one table
On 11/26/2011 09:45 PM, Paul M Foster wrote: On Sat, Nov 26, 2011 at 01:26:49PM -0600, Tamara Temple wrote: muad shibani wrote: i wanna to create one table that contains both news and articles posts, they have similar columns like id, title, content, and date but they are differ in one column = the source of news or article post article has writers that have permanent names and pictures obtained from another table called writers that supposed to be left joined with the news table, while news posts simply have a source as text like AFP or Reuters and so one. How I can solve this ? How you store things in tables can sometimes get a little tricky. One way to approach this is with normalized tables and using joins in your query like you are doing. To make this work, in your main entries table, have a field that indicates what the entry type is. If you are doing one select that gets both articles and news stories, having that extra field can help you distinguish what type it is, and which fields contain data in each record. (cf: Wordpress wp_posts table for an example of how this is done. They store posts, pages, and attachments in a single table this way. I can't say if this is a better arrangement than keeping them in separate tables.) I've had to hack this table. It's a prime example of bad design. Take a long look at the records of this table in an active blog, with a survey of each of the fields and their values. You'll see what I mean. Paul The Drupal approach to this problem is to have a common table for all "nodes" (our generic content object thingie), and then dependent tables for type-specific stuff. So (over-simplifying): node: id, title, type, created time, updated time, published (1 or 0) field_body: node_id, delta, value field_picture: node_id, delta, url field_source: node_id, delta, url to reuters or whatever field_writers: node_id, delta, writer name, url to writer picture // etc. That way, you can have the basic information all in one table and then specific fields can be shared by some, all, or just one node type, and all can be multi-value. It does mean loading up a full object is multiple queries, but really, MySQL is fast. You don't need to over-optimize your query count, and this gets you a well-normalized database. If you know in advance exactly what your types are going to be (in Drupal they're user-configurable), you could simplify it to something like: node: id, title, type, body. created time, updated time, published (1 or 0) node_article: node_id, writer name, writer picture url node_news: node_id, url to reuters or whatever And you can still select on whatever you need. With a LEFT JOIN, you can even get back all data on all articles of both types, and just have lost of nulls in the result set for the off-record fields. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP exercises
Hi folks. A friend of mine is trying to learn PHP. She already knows programming basics, but wants to learn PHP specifically. However, she learns much better with assignments or exercises than just from reading articles or books. The only site I've found so far is PHP Exercises (http://phpexercises.com/), but it of course went offline the day after I found it. Fail! Can anyone recommend other sources for tutorial-based or exercise-based PHP learning? Paid is OK if it's not too expensive and it's worth the money, although free is always preferred. TIA and all that. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Headers already sent
Perhaps your server is configured to have output buffering enabled by default? Check php.ini / phpinfo(). --Larry Garfield On 11/11/2011 12:12 AM, Kranthi Krishna wrote: Hi all, I am missing something pretty obvious here. The PHP Manual says "Remember that header() must be called before any actual output is sent, either by normal HTML tags, blank lines in a file, or from PHP.". A simple test case shows otherwise I have the following code test http://goo.gl/e6t3 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Books on PHP guts
Hi folks. I'm not looking to write new PHP extensions per se, but am looking to better grok the guts of PHP itself. (That's a first step on the way to writing new extensions, though. Gateway drug!) I'm especially interested in the memory/performance implications of various techniques. Are there any good books on the subject that would be of help? I'm familiar with Sara Goleman's book[1], which has generally good reviews, but it's several years old now and I'm not sure if there's anything newer that covers PHP developments since the 5.0 days. Any suggestions? --Larry Garfield [1] http://www.barnesandnoble.com/w/extending-and-embedding-php-sara-golemon/1006978211 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
On Wednesday, January 19, 2011 8:56:50 pm Tommy Pham wrote:
> > And actually, thinking about it, I wonder if requiring the explicit
> declaration
> > is a good thing anyway because then it's immediately obvious and
> > greppable what the class does. :-)
> >
> > --Larry Garfield
>
> You mean requiring explicit declaration of
>
> > class Bob implements Foo {
> >
> > }
>
> It's so you can guarantee your app from future breakage because the
> interface guarantees minimum functionality and still maintain great
> flexibility such that:
Well, let me offer a more precise example of what I want to do:
interface Stuff {
function doStuff($a);
}
interface Things extends Stuff {
function doThings($a);
}
class Bob implements Stuff {...}
class Alice implements Stuff {...}
class George {}
class Matt implements Things {...}
function make_stuff_happen($o) {
foreach (class_that_implements_stuff() as $class) {
$c = new $class();
$c->doStuff($o);
}
}
The above code should iterate over Bob, Alice, and Matt, but not George. The
trick is how to implement class_that_implements_stuff() (or rather,
class_that_implements_something('Stuff')) in a sane and performant fashion
that supports auto-loading.
If all of the above is together in a single file, it's dead simple with
get_declared_classes() and class_implements(). However, in practice there
could be some 200 interfaces -- with each installation having a different set
of them -- and as many as 500 classes implementing some combination of those
interfaces, possibly multiple on the same class -- also with each installation
having a different set of them. I do not want to be forced to include all of
those classes and interfaces on every page load when in practice only perhaps
two dozen will be needed on a particular request. That makes
class_that_implements_stuff() considerably tricker.
That let naturally to having a cached index (in a database, in a file with a
big lookup array, whatever) that pre-computed which class implements what
interface and what file it lives in, so that we can easily lookup what classes
we need and then let the autoloader find them. (Previous benchmarks have
shown that an index-based autoloader is actually pretty darned fast.) That
just makes building that index the challenge, hence this email thread.
Thinking it through, however, I am now wondering if, in practice, indirect
implementation (class Matt above) will even be that common. It may not be
common enough to be an issue in practice, so requiring Matt to be declared as:
class Matt implements Stuff, Things {...}
isn't really that big of a deal and makes the indexer considerably simpler.
We actually have one already that indexes class locations; it just doesn't
track interfaces.
I also, on further review, don't think that class-based inheritance will ever
be an issue. The following:
class Mary extends Alice {...}
Would not make much sense at all because then both Mary and Alice would run,
so Alice's code would run twice. So I may be over-complicating the situation.
(For those following along at home, yes, this is essentially observer pattern.
However, it's on a very large scale and the thing being observed may not
always be an object, so the usual active registration process of instantiating
both objects and telling them about each other on the off chance that they
*may* be needed is excessively wasteful.)
Does that make it clearer what I'm trying to do?
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Class and interface location
Hi all. I'm trying to come up with a solution to an architectural problem I could use some extra eyes on. I have (or will have) a large code base with lots of classes, spread out over many optional plugin components. These classes, of course, will have interfaces on them. These classes will, of course, lazy-load using PHP's autoload capability. What I need to know is which classes implement which interfaces, so that I can load and use "all classes that implement interface Foo". There are a couple of approaches that I've considered, all of which I dislike for one reason or another. 1) Magic file naming. That is, any class that implements interface Foo lives in a $something.Foo.inc file, or some similar pattern. This has a number of problems. First, it means a huge number of file_exists() calls to determine if a given potential class exists, and then disk hits to load those files. While that information is possible to cache, it also means that we cannot have a class that implements two of the interfaces I'm interested in (a feature I will need) because then it would have to live in two files, which is clearly impossible. 2) Reflection. PHP makes it quite easy to get a list of all loaded classes, and to get a list of all interfaces that a loaded class implements. The catch there is "loaded". Reflection only works once you've loaded the code file into memory. Once you've done so, you cannot unload it. That means the code is sitting there in memory wasting space. Given the size of the code base in question, that could easily blow out the process memory limit. Even if we cache that information we derive from reflection we still have to load it the first time (or periodically when rebuilding the cache), which will blow the memory limit. The only alternative would be to have some sort of incremental rebuild across a multi-request batch process, the complexity of which makes my skin crawl. 3) Static analysis. Instead of reflection, either tokenize or string parse all files to determine what classes implement what interfaces and then cache that information. We are actually using this method now to locate classes, and it works surprisingly well. Because we never parse code into memory it does not ever spike the memory usage. However, it is impossible to determine if a class implements a given interface by static analysis unless it declare so itself with the implements keyword. If it does so indirectly via inheritance, either via the class or via the interface, it would not find it. That necessitates that any "detectable" classes must explicitly themselves declare their interfaces, even if it is redundant to do so. I don't like that approach, but it's the first one that strikes me as even viable. 4) Explicit declaration. In this approach we detect nothing and rely on the plugin developer to do everything. That is, they must provide somewhere (either in code or a configuration file) an index of all classes they offer, the interfaces they implement, and the file in which they live. While this makes the implementation easy, it is a huge burden on the plugin developer and I'm quite sure they'll forget to do so or get it wrong on a regular basis. 5) Wave a wand and let the magic ponies figure it out. I wish. :-) Can anyone suggest a better alternative? At the moment option 3 seems like the most viable approach, but I'm not wild about the implied performance impact nor the potentially redundant interface definitions it would require. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Closure and $this
On Wednesday, January 12, 2011 11:37:19 pm Greg Bair wrote: > On Wed, 12 Jan 2011 20:02:11 -0800 (PST) > > Raymond Irving wrote: > > Hello, > > Does anyone know if closures will ever support the $this keyword? > > I think it would be very useful when working with objects. > > > > Best regards__RaymondDo more with less - http://raxanpdi.com > > Probably not, and my understanding of why comes from this line from the > docs (http://www.php.net/manual/en/functions.anonymous.php): > > "Anonymous functions are currently implemented using the Closure class." > > So, in other words, your closure does not belong to the class you > declare it in, but the Closure class. > > Thus, if it supported the $this variable, it would refer not to the > class you want, but instead to the Closure class. > > Just my understanding. If it's not right, someone point it out. Actually at one point early on they did support a $this, but the way it was bound to an object was half-assed and incomplete so it was removed entirely from 5.3. The intent was to then properly think through how that binding should happen and re-introduce it properly in 5.4. I believe a consensus was reached on how that should happen but I'm not sure what its implementation status is at present. I believe this is the relevant RFC: http://wiki.php.net/rfc/closures/object-extension --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Command line PHP
On Friday, January 07, 2011 9:34:42 pm David Hutto wrote: > Which yielded this as the first result: > > > http://php.net/manual/en/features.commandline.php As noted in my original email, I find the native SAPI clunky and difficult to work with. Hence I was looking for something more usable and robust built on top of it that I could leverage rather than rolling my own one-off. Of course, I got lost somewhere in the language holy wars (dear god, people...) so I'll probably just take the "roll my own" approach. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Newbie Question
On Sunday, January 02, 2011 4:56:28 pm Adolfo Olivera wrote: > Thanks for the replies. I'll just put a php on all my html containing php. > A little of topic. Wich IDE are you guys using. I'm sort of in a catch > twenty two here. I been alternating vim and dreamweaver. I'm trying to go > 100% open source, but I really find dreamweaver easier to use so far. I bounce between NetBeans and Eclipse, depending on which currently sucks less. I have yet to find a PHP IDE that doesn't suck; it's just degrees of suckage. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PDO: good, popular?
On Tuesday, December 14, 2010 1:02:33 pm Lester Caine wrote: > la...@garfieldtech.com wrote: > > I'm the DB maintainer for Drupal 7, and we rebuilt our entire DB layer > > on top of PDO. It's a rather nice API, although as others have noted it > > does not abstract away SQL entirely; it abstracts the API calls you need > > to use to get to SQL. > > > > We then built a layer on top of that which does abstract away most > > database weirdness using fluent query builders. It's much > > lighter-weight than an ORM. I'm in the process of spinning it off as a > > stand-alone library because we think it's that cool, but it's not > > completely divorced from Drupal yet. Stay tuned. :-) > > Larry - how many databases does it actually work with? Having rebuilt the > DB layer using PDO did you actually gain anything? Drupal 6 and earlier supported MySQL and, kinda sorta, Postgres, maybe. Drupal 7 ships with support for MySQL, Postgres, and SQLite out of the box and add-on modules provide support for Oracle and MS SQL, within reason. So we increased our DB support from 1.5 to 5, essentially. We also gained, as part of the rewrite, untyped prepared statements, transactions, and master/slave support (although that's nothing to do with PDO per se, just our layer on top of it). And that allowed us, in turn, to build type-safe query builders, support for MERGE queries, and all kinds of other fun stuff on top of that. > PDO still needs a number of areas finishing before it can become a total > replacement for the legacy stuff that is available such as the PEAR > libraries and the likes of Drupal writing their own abstraction layer on > top of it ... along with a number of other projects who are now doing the > same thing ... shows that PDO is not creating the common platform it was > supposed to :( That is, sadly, true. PDO is not a complete and perfect DB library, in part because there are few people who work on it, and fewer still who understand all of the vendor-specific issues at hand and the vendors have been very slow to lend a hand, preferring to work on proprietary APIs. It's quite unfortunate, but I still consider PDO an overall win. If anyone knows C and wants to make a name for themselves in the PHP world, PDO is looking for some heroes. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] ORM doctrine
On Thursday, December 09, 2010 12:45:38 pm David Harkness wrote: > On Wed, Dec 8, 2010 at 11:11 PM, Daevid Vincent wrote: > > Avoid these ORM things like the plague! . . . Not to > > mention all that fancy "ORM" doesn't come without a price. It costs in > > terms > > of speed, as well as training. > > If you value CPU time over developer time, by all means avoid ORM > frameworks (and *all* frameworks). The point of a common framework is to > trade a small bit of performance for a large amount of developer time. If > you will only use the framework once, the payoff will be much less. The > goal is to choose frameworks that you can leverage again and again. > > As for training, you will be able to hire another developer that knows > Doctrine. It will be impossible to find a developer *anywhere* that > understands your home-grown framework without training. Nor will you get > help with bugs in your framework or be able to discuss better ways to use > it on forums. > > That being said, there are times when it's better to write your own code. I > will do this if the options out there don't suit my needs or if they seem > under-supported. For example, while we use PHPUnit and Zend MVC in our > apps, I wrote my own TestCase subclasses instead of using Zend's. I had to > write documentation for the other developers, and I must maintain it as > needs change. It was not a decision I took lightly. > > David ORMs are fundamentally fighting the wrong battle. They have their use, but in general they are architecturally not something you want to build your entire system on. See: http://www.garfieldtech.com/blog/orm-vs-query-builders http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Disk IO performance
There are many things that everybody "knows" about optimizing PHP code. One of them is that one of the most expensive parts of the process is loading code off of disk and compiling it, which is why opcode caches are such a bit performance boost. The corollary to that, of course, is that more files = more IO and therefore more of a performance hit. But... this is 'effin 2010. It's almost bloody 2011. Operating systems are smart. They already have 14 levels of caching built into them from hard drive micro-controller to RAM to CPU cache to OS. I've heard from other people (who should know) that the IO cost of doing a file_exists() or other stat calls is almost non-existent because a modern OS caches that, and with OS-based file caching even reading small files off disk (the size that most PHP source files are) is not as slow as we think. Personally, I don't know. I am not an OS engineer and haven't benchmarked such things, nor am I really competent to do so. However, it makes a huge impact on the way one structures a large PHP program as the performance trade- offs of huge files with massive unused code (that has to be compiled) vs the cost of reading lots of separate files from disk (more IO) is highly dependent on the speed of the aforementioned IO and of compilation. So... does anyone have any actual, hard data here? I don't mean "I think" or "in my experience". I am looking for hard benchmarks, profiling, or writeups of how OS (Linux specifically if it matters) file caching works in 2010, not in 1998. Modernizing what "everyone knows" is important for the general community, and the quality of our code. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] CMS plugin support
On Friday, October 22, 2010 4:30:06 am Emil Guy wrote: > Hi! > > I have a bit of a vague question. I have always used different selfmade > basic "CMS" for web pages. That works fine, and I like having my own > structure and light code weight. But the big pro with using a standard CMS > like drupal is the plugin support. Are there any php plugin standards or is > there a doable way of implementing support for drupal (joomla, whatever) > plugs? Of course there are php libraries, but I would like something more > lika a visual gadget and extremly fast implementation. I created a > wordpress blog instead of using my own code a while ago, and implementing > twitter support, antispam, etc was just two clicks and 2 min work, instead > of reading a manual for a library and maybe half an hour an hour work > implementing and debugging. And that was a nice change. > > When you make normal simple web pages do you guys use a ready-made CMS as a > base or do you have a self-made php template, or self-made cms, or what > solutions do you use? > > Kind Regards Emil Edeholt The ready availability of a bajillion plugins and a large community of people who can support me in writing more is one of the key reasons that virtually all of my web work these days uses Drupal. AFAIK there is no cross-CMS plugin system in PHP, and given how architecturally different various systems are I don't know that one would even be possible. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] the state of the PHP community
On Thursday 29 July 2010 02:07:58 am you wrote: > Hi Larry, > > Thanks for taking the time to reply, a solid insightful one at that - > kudos +1 for your opensource drupal efforts! > > Good of you to mention, and indeed to see, Palinter grasping opensource > with two hands, this is certainly a very credible approach to business > which deservedly reaps good rewards; testament to this is Day Software > (including of course Roy T. Fielding) which it seems is just about to be > bought by Adobe, a big +1 for this approach; and one I hope to see more of. > > With regards drupal development, there is a rather interesting chap > called Stéphane Corlosquet [ http://drupal.org/user/52142 ] who does a > fair bit of committing and really pushes the semantic web / linked data > side of drupal - definitely worth keeping tabs on. Oh I'm familiar with Scor. I've talked with him before about a project I'm working on that is using the amorphous, ill-defined beast known as RDF. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] the state of the PHP community
to bring some sort of sanity to the PHP dev process before finally giving up in despair. I really do respect what he was doing and wish he'd been more successful. - If I still remembered enough C to do so and had time to do so I'd try to work on PDO. Sadly I don't have either. PDO is in desperate need of help, apparently, and everyone is standing around waiting for someone else to do something about it. Given that databases are kinda critical for most PHP apps that is a non-small problem. > Do you network with other PHP'ers in real life - meetups etc, do you > tend to shy away, or do you find you circulate in other web related but > non PHP focussed communities? Mostly my work in the Drupal project eats up 99.9% of my community networking time, so I have very little left over for general PHP networking. I used to be somewhat active in the Chicago PHP users group but haven't been for some time. > Are you a member or any other web tech communities, opensource efforts, > or standardization bodies - again, if so which? I'm one of the lead developers of Drupal (although the term is very vague in the Drupal world), and the Database subsystem maintainer for Drupal 7 and later having written most of it. I am also in my 3rd year as a member of the Drupal Association Board of Directors as Director of Legal Affairs. I was also the lead organizer of the GoPHP5 effort a few years ago that managed to finally kill off PHP 4. In theory I'm the Drupal rep to the "PHP Standards" working group, but I think that group has pretty well died. > Are there any efforts, projects or initiatives which are floating your > boat right now and that your watching eagerly (or getting involved with)? Just lots of stuff within the Drupal world, which is large enough to keep me busy. I won't bore you with details. Come to DrupalCon Copenhagen next month if you want such details. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] CakePHP, alternatives?
One other thing I will add: Don't just learn PHP. Learn Javascript as well. Don't treat it as PHP without dollar signs, but learn Javascript as Javascript, and PHP as PHP. Then after you've gotten some time with those, take some time to learn, or at least learn about even if you never work with it, Erlang. Or Haskel. Or some other stricter, purely functional language. Something that works totally differently than PHP. Even if you don't ever use it, the perspective you gain from approaching a problem from a different angle will help you learn about the strengths and weaknesses of different languages, different ways of thinking, different ways of leveraging your tools well, etc. The 6 hours or so I spent reading about Erlang and purely functional languages helped my PHP skills considerably, even though I never wrote a single line of Erlang. (I was already very solid in PHP at the time, but it made me even better.) --Larry Garfield On Saturday 05 June 2010 12:51:47 am Shreyas wrote: > @ All - Points duly noted. Thanks for all the mighty advice. > > As the owner of the thread, I consider the thread closed for now unless > anyone has anything to add. > > --Shreyas > > On Sat, Jun 5, 2010 at 1:02 AM, Adam Richardson wrote: > > > I am reading this PHP for Dummies and then I plan to read Head First > > > with PHP, MySQL, and Apache. Do you know any books that I can read > > > online or I can buy? I would be happy to do that. > > > > Hi Shreyas, > > > > I think you've received some excellent advice. > > > > I like the Head First Books quite a bit. I attended grad school for > > cognitive psychology, and I can tell you that the Head First Books do a > > great job of integrating methods shown to enhance learning. > > > > I own several of the books in the series, including those on iPhone > > development and Design Patterns, and while I don't own the PHP book, I've > > reviewed it at the book store and recommend it to some friends who have > > taken up PHP, too, and they've been very pleased with the resource. > > > > I hope you have an enriching, enjoyable experience as you learn PHP. > > > > Adam > > > > -- > > Nephtali: PHP web framework that functions beautifully > > http://nephtaliproject.com > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] iCal parsing and processing
Hm. Thanks, but it looks like that's all in Python. I'm not a parcel tongue so that wouldn't be much use to me in a PHP app. :-) Thanks though. --Larry Garfield On Tuesday 25 May 2010 06:43:30 pm Jason Pruim wrote: > Hi Larry, > > Take a look at: http://trac.calendarserver.org/ > > It's Apple's open source page which includes their iCal web server... > Maybe something can be pulled from that? Just something to think > about and see if it helps :) > > Also... Not sure if you've looked at the CalDav protocol but that is > what it basically runs off of so if you haven't checked it out, you > might get some better results :) > > On May 25, 2010, at 2:10 PM, la...@garfieldtech.com wrote: > > Hi folks. I am looking for a good iCal processing library (open > > source / GPL compatible). Unfortunately, everything I've been able > > to find so far is half-assed, incomplete, buggy, or so horribly > > designed that I'd be embarrassed to use it (or several of the > > above). I was hoping someone could recommend one that actually > > works. I'd prefer an OO interface as it seems a natural fit, but at > > this point I'll settle for whatever works. > > > > I am not looking for an application with UI and form integration and > > stuff. I just want a working stand-alone parser. (If it can be > > ripped out of something more complete, that's fine.) > > > > My needs: > > 1) Given raw data (provided by a user form that I can already > > handle), construct iCal VEVENT information including RRULEs and > > EXRULEs. > > 2) Given a VCALENDAR / VEVENT object, generate the appropriate iCal > > text string that I can write to a file or return to the browser with > > the appropriate mime header. > > 3) Given a VCALENDAR / VEVENT object with RRULEs and EXRULEs in it, > > be able to say "give me the start/end dates of the next X > > occurrences from some date" or "give me all the start/end dates of > > occurrences until date Y". > > > > What I've found so far: > > > > http://www.kigkonsult.se/iCalcreator/ - This is the best I've found > > so far, and it's what I'm using now. It's missing requirement #3, > > though, as near as I can tell. Actually if I could add that > > functionality to it without too much trouble I'd probably stick with > > it, but it's non-trivial functionality. It's also PHP 4 OO, but I > > can deal. > > > > http://phpicalendar.net/ - This claims to do #3, I think, but it's > > integrated into a web app. The code for it is also horrific, as the > > entire parser is build on include files that rely on global > > variables without using any functions. The security implications of > > that alone scare me to death to say nothing of side effects and > > stability. > > > > http://code.google.com/p/qcal/ - Documentation is sorely lacking, as > > it is listed as "pre-alpha, real alpha to be released in January". > > That post was made in December, and there's still no "real > > alpha". :-) So I can't really tell if it does what I need or not. > > > > A quick search turned up nothing in PEAR, and Zend Framework has > > only a proposal from 2 years ago, not an actual library. > > > > Any others I don't know about? This seems like an area that cries > > out for a good standard library, but as of yet I haven't found one > > that works. Help or pointers would be much appreciated. > > > > --Larry Garfield > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] class attributes and __construct
On Thursday 15 April 2010 08:37:40 am Ashley Sheridan wrote: > I know I could move it to __construct and give it a default value in the > arguments list, but that brings it's own problems. What if the argument > list grows too big, and which attribute would be deemed more important > than another that you might want to override it without specifying every > other? Is there a rule of thumb as to what belongs in __construct and > what does not? > > Thanks, > Ash > http://www.ashleysheridan.co.uk I tend to favor setting the default with the property itself rather than in the constructor, even if I expect the constructor to specify it. I really really hate having undefined variables. :-) So even if, for instance, I'm going to pass in a db connection object in the constructor I will define it in the class and set it to NULL rather than not setting to anything. OK, I'm a little OCD, but it works. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Constructor usage
On Sunday 04 April 2010 09:21:28 pm Paul M Foster wrote: > > So, I'll throw the question out. Who uses example 1 above vs. example 2 > > when writing dependency-injection-based OOP? Why? What trade-offs have > > you encountered, and was it worth it? > > One problem I have with "parameterless constructors" is this: When you > rely on setters to shape your object rather than the constructor, your > other methods cannot assume the object is in proper shape to be usable. > There's no guarantee the programmer won't forget one of the vital > setters. So each method in the object must test to ensure the object can > actually be used properly. This isn't a deal-breaker, but it seems like > an awfully unnecessary piece of additional code which must be replicated > in each method. (Naturally, this is moot where the class doesn't depend > on any outside objects or parameters to operate.) Yeah, I tend toward using constructors for injection for the same reason: That way I always know for sure that if I have an object, it's "complete". I defer most object instantiation to factories anyway, so in practice it's not a huge issue for me. > I've found that many of my classes require other classes in order to > operate. Moreover, they must be instantiated in the proper order, or > things fall apart. So I took the step of creating my own "dependency > injection instantiator" class which handles all this for me. Classes > with dependencies typically are specified so that the requisite objects > are passed to the constructor (the simplest way). Each class which is > managed by the DII is registered first, with whatever parameter or > object dependencies needed. Then the DII's "instantiate()" method is > called as needed for each object. The DII class handles instantiating > objects in the proper order and with the proper dependencies. The > programmer's job is made much simpler. > > Paul Sounds overly complicated, but whatever works. :-) In my experience so far I find that a well-designed factory is sufficient, but it may not be in larger or more involved OO frameworks than I've used to date. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Constructor usage
Hi folks. Somewhat philosophical question here.
I have heard, although not confirmed, that the trend in the Java world in the
past several years has been away from constructors. That is, rather than
this:
class Foo {
public void Foo(Object a, Object b, Object c) {}
}
Foo f = new Foo(a, b, c);
The preference is now for this:
class Foo {
public void setA(Object a) {}
public void setB(Object b) {}
public void setC(Object c) {}
}
Foo f = new Foo(a, b, c);
f.setA(a);
f.setB(b);
f.setC(c);
I suppose there is some logic there when working with factories, which you
should be doing in general. However, I don't know if that makes the same
degree of sense in PHP, even though the OO models are quite similar.
So, I'll throw the question out. Who uses example 1 above vs. example 2 when
writing dependency-injection-based OOP? Why? What trade-offs have you
encountered, and was it worth it?
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote: > On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop wrote: > > When looking at PHP as used in enterprise class applications, we can see > > the following happening. Let imagine that we have a site that gets a > > 1000 requests per second. That seems to be a good candidate for > > threading so as to be able to handle the 1000 requests per second. The > > site runs PHP and Apache. Well, what happens? Each request coming in is > > handed of to a separate instance of Apache. Thus the site would be able > > to process many requests simultaneously. It looks as if parallel > > computing is taking place here, which looks much like threading. Even > > though PHP itself does not know about threads, and does not need to, I > > think, the whole process of handling the 1000 requests per second uses > > parallel computing. There are no performance bottle-necks here. Teus. > > # of requests / second can be solved by load balancers/clusters. What > about the multiple answers for a simple request per user as in my > example? How you would solve that if not by threading? Amazon has > about 30 million products and they have filters similar to what I > mentioned. But when clicking on one of the I18n site at the bottom, > you're taken to another server, which looks like it uses a different > DB back end (I could be wrong) and you don't get instant translation > of the category you're looking at. Their response time is about 3 > seconds on my 10mbs (not cable) download. As for what programming > language they use... Honestly, how WOULD you solve that with threading? You describe a page that needs to be generated that has a half-dozen queries against the database ranging from simple to moderately complex, some of which are site-generic and some are user-specific. How does one solve that with threading? 1) Run the site-generic queries once and cache them in memory and let other threads just use that query result. You can do that without threads. Just render that part of the page and cache that string to disk, to the database, or to memcache. If the memecache server is on the same box then it should be identical to the threading version, performance-wise. (Give or take VM considerations.) 2) Push the user-specific DB queries to separate threads so they can run in parallel. All that does is push the hard work off onto the DB server, which is still running the same number of queries. And PHP can't respond until all of the queries finish anyway, and the DB server will respond no faster, so you're really gaining nothing. You keep saying "how would you solve this without threads?" as if they're some magical speed fairy dust. Given the scenario you describe, I don't even see how threads would buy you anything at all. Where threads would be useful is for lots of very small writes on rapidly changing data. I would never want to write, say, the World of Warcraft servers without threading and a persistent runtime, but then I wouldn't want to write them in PHP to begin with. Insert that old saying about hammers and nails here. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Monday 22 March 2010 10:51:14 pm Tommy Pham wrote: > Threading is one of the 2 two main reasons why I moved to Java & > asp.net (C#). I've built a PHP based web crawler about 10 years ago. > I ran into some problems: cookies, form handling and submission, > threading, and application variables. I later found some solutions > for cookies, form handling & submission. But no solution for > threading and application variables. Thus the move. Here's a simple > example of one of the many uses for threading. For an e-commerce > site, when the shopper requests for a category (ID), you can have a > thread to get all subcategories for that category, another thread to > get any assigned products, another thread to fetch all manufacturers > listed under that category, another thread to fetch any filters (price > ranges, features, specs, etc) set by the store owner that would fall > under that category, etc... versus what PHP currently doing now: > fetch subcategories, then fetch assigned products, then fetch > manufacturers, etc Performance would increase ten fold because of > parallel (threading) operations versus serial operations. Add that to > application variable (less memory usage and CPU cycles due to > creating/GC of variables that could be used for an entire application > regardless of requests & sessions), you have an excellent tool. > > Regards, > Tommy Threading is also much more difficult to program for safely, because thread order is non-deterministic. Do you really want to unleash hoards of marginally competent programmers on a threaded enviornment? :-) Also, the architecture you describe above is fine if you're scaling a single server really big. PHP is designed to scale the other direction: Just add more servers. There's no data shared from one request to another, so there's no need to share data between web heads. Throw a load balancer in front of it and spin up as many web servers as you need. The "shared nothing" design is very deliberate. It has design trade-offs like anything else. PHP is a web-centric language. It's not really intended for building tier-1 daemon processes, just like you'd be an idiot to try and code your entire web app in C from the start. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Perhaps if you asked a question you'd get an answer rather than coming off as an angry immature crybaby in your last paragraph... No, I'm not going to dignify your post with a real answer. Come back when you can ask a real question and maybe you'll get a real answer. --Larry Garfield On Monday 22 March 2010 07:02:30 pm Daevid Vincent wrote: > I've been using PHP for a decade or so (since PHP/FI) and love it. The one > problem that seems to always keep coming back on enterprise level projects > is the lack of threading. This always means we have to write some back-end > code in Ruby or Java or C/C++ and some hacky database layer or DBUS or > something to communicate with PHP. > > Will PHP ever have proper threading? It would sure let the language take > the next logical leap to writing applications and daemons. I love the idea > that Rails/Ruby have where you can just load objects in memory once and > keep using them from page to page (this is NOT the same as a $_SESSION, > it's way more flexible and powerful). > > But more importantly, in one application I'm working on, we need to connect > to an Asterisk system for the IVR abilities. This means we have Ruby doing > all that fun stuff and PHP doing the web stuff, but we're also duplicating > a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's > calling in, advertisements served, products shown, etc. We could have used > Rails for the web portion, but I want to stay with PHP and I'm sure I don't > have to explain to you PHPers why that is. Without threads, PHP just isn't > even an option or only one user would be able to call in at a time. > > The pcntl stuff is not feasible. It's a hack at best. Spawning multiple > scripts is also a recipie for disaster. > > When will the PHP core-devs (Zend?) realize that PHP is much more than a > hook to a database. It's much more than web pages. > > Is this a case of "it's too hard"? Or is it a case of PHP core developers > just being douche-bags like they are about the whole > "foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let > the developer choose WHICH of the list of parameters they want to set in a > function/method call aside from being stubborn! Especially when there are > many parameters and you can't overload functions like you can in Java or > other typed languages) > > As usual, I created a poll here too: > http://www.rapidpoll.net/awp1ocy > > Past polls are below: > http://www.rapidpoll.net/8opnt1e > http://www.rapidpoll.net/arc1opy (although someone hacked this poll and > loaded up the 76 votes like a little cheater) > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Code samples in OOo Presenter
On Sunday 21 March 2010 05:41:55 pm Ashley Sheridan wrote: > > I don't like any of these options. :-) I don't know what the alternative > > is, though. Ideally I'd love to have a custom text region or format or > > something that is "take this and highlight it properly", but I don't know > > if such a plugin exists. > > > > I could be talked into using KPresenter / KOffice instead if that would > > be easier, but as I am on Linux I have no access to KeyNote or > > PowerPoint. > > > > Any suggestions? > > > > --Larry Garfield > > Could you use highlight_string() on the code example in a web page then > copy that from the browser and paste that into your presentation? It > should then preserve the formatting used on the browser display, and let > you easily modify the font size. > > Thanks, > Ash > http://www.ashleysheridan.co.uk I will have to see if OOo preserves formatting when I do that. However, that still leaves the problem of highlight_string()'s colors being rather poor for on-screen. Are those easily configurable? That would at least give me a decent result, kinda, even if it's not as clean as doing it all within the presentation program. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Code samples in OOo Presenter
Hi all. I have a busy conference season coming up, and will be giving a number of presentations that involve code, specifically PHP. I am going to want to put code onto slides in OpenOffice (3.1 specifically, using Kubuntu 9.10), but to date I've never figured out a good way to do that. Anyone know of a good way to do syntax-highlighted code in OOo? Things I've tried in the past: 1) Just throw code onto the slide, no highlighting. This works, but is ugly and harder to read or demonstrate what I am doing. It's my usual fallback. 2) Screen-shot from a web page that uses syntax highlighting, such as PHP's built-in highlighting. Very difficult to prepare since the sizing is usually all off. Ugly. Very difficult to edit and change because the screen caps have to be regenerated. And PHP's default coloring for highlighting frequently clashes with the slides and looks godawful on a projector. (I once ended up with blue text on a black slide. That was a major fail.) 3) Jump out of the slides into an IDE. Works, but totally breaks the flow of the presentation. The IDE usually also has text that's way too small, and I have to reconfigure it into a "presentation mode", often on the fly. It also makes discrete snippets harder to show, since there's still the entire rest of the IDE there. I don't like any of these options. :-) I don't know what the alternative is, though. Ideally I'd love to have a custom text region or format or something that is "take this and highlight it properly", but I don't know if such a plugin exists. I could be talked into using KPresenter / KOffice instead if that would be easier, but as I am on Linux I have no access to KeyNote or PowerPoint. Any suggestions? --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Memory investigation
Hi folks. I have a complicated PHP app that is eating up more memory than I think it should. I have a couple of theories as to where it could be going, but I need some way to verify it. There are a number of large data structures (mostly arrays) that get built up throughout the course of the request. What I'd like to be able to do is at certain points check to see how much memory those data structures are using. Because they're not all built at once, the usual "check memory before, build, check after" routine won't work. Plus, that gets screwed up by PHP's use of copy-on-write at times. I know that it would result in essentially over-reporting, but I would ideally like to be able to ignore the copy-on-write issue and say "if this variable were the only thing in memory (and its dependents, of course, for a nested array), what would its memory usage be? I just have no idea how to do that. Anyone have a suggestion for how to accomplish that? --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] array conversion
On Thursday 18 February 2010 11:58:28 pm Paul M Foster wrote:
> On Fri, Feb 19, 2010 at 01:20:12PM +0800, Dasn wrote:
> > Hi guys. How to convert an array like:
> >
> > Array
> > (
> > [0] => key1
> > [1] => value1
> > [2] => key2
> > [3] => value2
> > )
> >
> > to
> >
> >
> > Array
> > (
> > [key1] => value1
> > [key2] => value2
> > )
> >
> > Is there a built-in function to do this?
> > Please Cc me. :)
> > Thank you in advance.
>
> I don't believe so, but rolling your own should not be too hard:
>
> $a = array($key1, $value1, $key2, $value2);
> $b = array();
> $numitems = count($a);
>
> for ($i = 0; $i < $numitems; $i++) {
> if ($i % 2 == 0) {
> $saved_key = $a[$i];
> }
> elseif ($i % 2 == 1) {
> $b[$saved_key] = $a[$i];
> }
> }
>
> Code is crude and untested, but you get the idea.
>
> Paul
This would be even shorter, I think:
foreach ($items as $i => $value) {
$temp[$i % 2][] = $value;
}
$done = array_combine($temp[0], $temp[1]);
(Also untested, just off the cuff...)
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL insert () values (),(),(); how to get auto_increments properly?
On Sunday 14 February 2010 03:15:16 am Rene Veerman wrote: > On Sat, Feb 13, 2010 at 3:46 PM, Joseph Thayne wrote: > > In order to make this as "sql server independent" as possible, the first > > thing you need to do is not use extended inserts as that is a MySQL > > capability. If you are insistent on using the extended inserts, then > > look at the mysql_info() function. That will return the number of rows > > inserted, etc. on the last query. > > But as previous posters had pointed out (thanks) i can't see which rows > failed. As i'm dealing with 3rd-party data, that's an issue. > > I also didn't know it was mysql-specific, that multi-insert.. > > And i tried looking up the sql-standard docs, only to find that they > cost over 200 euro per > part (14 parts). > I've sent angry emails to ansi.org and iso.org (commercial lamers > operating under .org, yuck), about how cool a business model that > charges a percentage of profits per implementation would be, instead > of charging high prices up-front for a potentially bad/complicated > piece of spec. > > But back to the problem at hand; it looks like i'll have to forget > about using 100s of threads for my newsscraper at the same time, and > settle for a few dozen instead. > Then i can just do single inserts (per hit) and retrieve the > last_insert_id(). > > One question remains: it is probably not (concurrently-)safe to do a > sql-insert from php and then a last_insert_id() also from php..? > I still have to build a stored procedure to do-the-inserting and > return the last_insert_id()? That's perfectly safe to do as long as it's within the same PHP request. (Well, the same DB connection, really, which is 99% of the time the same thing.) last_insert_id() is connection-specific. I believe (it's been a while since I checked) the MySQL documentation says that last_insert_id() with a multi-insert statement is not reliable and you shouldn't rely on it having a worthwhile meaning anyway. Or at least it said something that made me conclude that it's safest to assume it's unreliable for a multi-insert statement. If you're concerned about performance of that many bulk writes, there's 3 things you can do to help: 1) Use InnoDB. It uses row-level locking so lots of writes doesn't lock your whole table as in MyISAM tables. 2) Disable indexes on the table in question before running your bulk insert, then re-enable them. That's considerably faster than rebuilding the index after each and every insert as they only need to be rebuilt once. 3) If you're on InnoDB, using transactions can sometimes give you a performance boost because the writes hit disk all at once when you commit. There may be other side effects and trade offs here, though, so take with a grain of salt. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Open Source CMS
On Wednesday 20 January 2010 10:29:38 pm Hendry wrote: > Hi, > > Thanks for both Robert and Allen for sharing, I agree, Drupal is very > easy to start with, and it is also very powerful, but somehow, I find > it very hard to extend which is might be due to my lack of experience. > > # Hendry The way you extend Drupal is rather different than most other systems due to its architecture. However, once you wrap your head around doing so it is extremely extensible. The online docs on drupal.org are a pretty good place to start, but I can also recommend this book: http://www.packtpub.com/drupal-6-module-development/book Disclaimer: The author used to work with me, and I'm a Drupal core developer so I am admittedly biased. :-) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
e. Yes, always blindly following a given design pattern for the sake of following a design pattern is stupid. Blindly ignoring established "solved problems" just for the sake of avoiding those pointless design patterns is just as stupid. Remember, code is irrelevant. You don't sell code. You sell ideas and concepts, implemented in code. By not having to re-invent the ideas and concepts every time, you can save a great deal of time and effort, and potentially a great deal of code that you don't need to rewrite later from going down a dead-end. There's two kinds of developers: Those that understand how they're using design patterns and those that don't understand design patterns. :-) But both are, in practice, using them, even if some are doing so badly (either over- or under-using them). --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
Meant to send this to the list, sorry. -- Forwarded Message -- Subject: Re: [PHP] If design patterns are not supposed to produce reusable code then why use them? Date: Thursday 31 December 2009 From: Larry Garfield To: "Tony Marston" On Wednesday 30 December 2009 10:50:40 am Tony Marston wrote: > I have recently been engaged in an argument via email with someone who > criticises my low opinion of design patterns (refer to > http://www.tonymarston.net/php-mysql/design-patterns.html ). He says that > design patterns are merely a convention and not a reusable component. My > argument is that something called a pattern is supposed to have a recurring > theme, some element of reusability, so that all subsequent implementations > of a pattern should require less effort than the first implementation. If > design patterns do not provide any reusable code then what is the point of > using them? > > > > I do not use design patterns as I consider them to be the wrong level of > abstraction. I am in the business of designing and developing entire > applications which comprise of numerous application transactions, so I much > prefer to use transaction patterns (refer to > http://www.tonymarston.net/php-mysql/design-patterns-are-dead.html and > http://www.tonymarston.net/php-mysql/transaction-patterns.html ) as these > provide large amounts of reusable code and are therefore a significant aid > to programmer productivity. > > > > What is your opinion? Are design patterns supposed to provide reusable code > or not? If not, and each implementation of a pattern takes just as much > time as the first, then where are the productivity gains from using design > patterns? It depends what you're reusing. Design patterns are reusable concepts, not reusable code. That's the key difference. Knowledge of design patterns is like knowledge of how different food ingredients interact. "Hm, this needs something to bring out the taste more, so I'll add salt." You're not going to add the same salt to each dish, obviously, but the idea is that you need something that will bring out the taste, and there are certain spices that will bring out the existing taste of whatever it is you put them on, such as salt. Similarly, if you want, say, a piece of code that will connect to a database, you want a pre-built library, not a design pattern. (There's no shortage of those.) If, however, you want a mechanism by which you can have different implementations of the same system, and want to swap them out without rewriting the calling code, then what you want is the factory *pattern*. There may not be existing code yet for whatever system you're writing. However, once you recognize "Ah, I want a common interface with a swappable implementation, and I want to pick the implementation at runtime based on some arbitrarily complex logic", then you know you don't need to think through how you go about structuring the code to do that. Instead, you look up a description of the factory pattern and go "ah, that makes sense, and it solves 3 problems that I didn't realize I'd run into later". Then you go and implement code that follows that pattern, and you don't have to think through the algorithm. Now, it is possible to make generic implementations of some patterns that you can re-leverage. Eg, you can have a common factory interface and a way to request a factory, which in turn will give you the implementation object you want. The common elements of those factories you move up to a parent class, and therefore reuse code that way. This is known as a "Factory factory", and is in some cases very useful and in others gross over-engineering. Knowing which is which is something you learn through experience. --Larry Garfield --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multiple Inheritance Needed in OOP?
On Monday 28 December 2009 9:45:03 pm Daniel Kolbo wrote: > Hello, > > Okay so PHP designers explicitly decided against multiple inheritances, > but aren't there legitimate needs for multiple inheritance in OOP? > > For example, consider the following three classes (A,B,C) with the > following properties (a number is a distinct property or method). > > A: 1, 2, 3 > B: 1,3 > C: 1, 2, > > I would like to set the 3 classes up so that no object has 'extra' > properties than it requires, so that no property has to be > declared/defined in two or more classes, and so that we are strictly > using single inhertiance. I don't think it's possible. I've been > incorrect beforee...If i'm incorrect please let me know how to set this > up as a single inhertance class structure. > > If this is not possible, why doesn't the PHP community implement > multiple inheritance? (I'm anticipating that someone will say, you > simply need to redefine what you are calling your objects so that the > properties do permit a single inheritance...) > > I'm very interested to hear why there is the dogma of single inheritance > only. > > Thanks, > dK > ` Because pure multiple inheritance can lead to all sorts of highly weird behavior when you don't know which parent class you mean at any given time. Single inheritance is just easier to wrap your head around, and wrap the compiler's head around. What you're looking for is composition, which can do pretty much what you're looking for. See my last reply to you on this list from Christmas day. There's been some discussion of implementing "traits" in later versions of PHP, but no concrete patches so far. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Accessing Objects - Object to Object Communication
On Saturday 26 December 2009 3:38:44 pm Allen McCabe wrote:
> Here are some code snippets:
>
> Content.class.php:
> class Page {
>
> private $db;// Contains reference to instance of the
> Database class
> private $notify;// Contains reference to instance of the
> Notifier class
> private $URL;
>
> public function __construct($dbconnection, $root, $id = null)
> {
> $this->db = $dbconnection;
> $this->notify = Notifier::getInstance();
> $this->URL = $root . 'content/';
>
> if (isset($id)) {
> $result = $this->db->query('SELECT * FROM `content` WHERE
> `page_id` = \''. $id .'\'');
> $data = $this->db->fetch_array($result);
> }
> }
> }
>
> header.php:
> require_once('lib/class/Database.class.php');
> $db = new Database($dbhost, $dbuser, $dbpass, $dbname);
> $db->connect();
> require_once('lib/class/Notifier.class.php');
> $notify = Notifier::getInstance(); // self instantiates
> require_once('lib/class/Content.class.php');
> $page = new Page($db, ROOT);
>
>
> Does this look right? I don't think I've ever seen two -> operators
> together like this before...
>
> I don't want to keep connecting to the database, and more importantly, my
> Notifier class should only be a single instance, so I need to be able to
> amend to a static array variable in that class from within other classes.
>
> Thanks for any help you can provide, and happy holidays!
Chaining multiple -> operators together like that is totally fine, and what
you're doing here with the database is a good example of simple dependency
injection. In fact, you should do the same with the notifier class and pass it
into the constructor of Page as well rather than making it a syntactic
singleton.
For extra credit, wrap all of that into a factory function or factory object:
function create_page($root) {
$db = create_your_db();
$notifier = create_your_notifier();
return new Page($db, $notifier, $root);
}
$new_page = create_page($my_root);
And the db and notifier routines can be as simple or complex as needed for your
use case. They could be singletons themselves, but don't have to be. And in
either case, Page() now doesn't know or care so you can change your mind
without affecting Page. Page is now loosely coupled, and all is right with the
world.
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multiple Inheritance Concern
On Friday 25 December 2009 8:02:06 pm Daniel Kolbo wrote:
> Hello PHPers,
>
> I've learned that php doesn't support multiple inheritance, b/c if you
> need multiple inheritance usually it is a sign you've got a design
> imperfection...or so they say.
>
> Well, I'm using a framework (Codeigniter), and i'm extending the core
> libraries. The trouble is, I want to also extend a second custom class,
> and I don't want to change the core codeigniter class definitions as
> this makes for awkward upgrades.
>
> I read about mixins - no thank you. i do not want to even think about
> mixins as it looks like it would be the source of all debug hell...
>
> What's a programmer to do? Is the only option i am really left with to
> duplicate the code in each class?
>
> Thanks,
> dK
> `
If the original author of one or both libraries did their job right, they'll
have provided an interface as well as the class that implements it. Then you
can implement the interface and pass through to a new instance using
composition.
To wit:
interface AInterface {
public function doA();
}
interface BInterface {
public function doB();
}
class A implements AInterface {
public function doA() { ... }
}
class B implements BInterface {
public function doB() { ... }
}
class YourClass extends A implements BInterface {
protected $b;
public function __construct() {
$this->b = new B();
}
public function doB() {
return $this->b->doB();
}
}
(It would probably be a little more complicated in a real use case, but
hopefully that should get you the idea.)
Mind you, that presumes that the code you're dealing with provides interfaces
and when doing type checking checks against the interfaces rather than the
classes themselves. If they don't, you should file a bug against that base
library as They're Doing It Wrong(tm).
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP Design Question
On Sunday 20 December 2009 1:08:46 pm you wrote: > >> Maybe this would be the perfect opportunity for the php autoload > >> functions...? > >> > >> Thanks for your help/thoughts/comments, > >> dK > >> ` > > > > Yep, this is a textbook case for a proper autoload setup. And no, > > cramming all of the functionality into one mega class won't get you any > > efficiency. In fact, it would be just as wasteful as loading all 60 > > classes even when you're only going to use 2; you're still loading up > > roughly the same amount of code. Parsing it as one mega class or one big > > parent with a few small child classes is about a break-even as far as > > performance goes, but the mega class is much poorer architecture. > > Thanks for your insight. > > I could probably setup autoloading, but I wonder if I would do it > 'properly'. Do you have a link or reference that you'd recommend for > howto do a 'proper autoload setup'? > > Thanks, > dK Well, there is no universal agreement on what a "proper" setup is. :-) There is a group trying to establish a Java-like standard for all projects to use once they get to PHP 5.3 and namespaces, but there are still issues to work out and IMO it's not actually a good approach for many use cases. I'd argue that "proper" depends in a large part on your specific use case. The most important aspect of a good autoload mechanism, though, is that it's fast and extensible. Use spl_autoload_register() instead of __autoload(), and make sure that you keep the runtime of your autoload callbacks to an absolute minimum. (A DB hit per autoload, for instance, is a no-no.) Beyond that, varies with your project. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] efficiency of include()
On Sunday 20 December 2009 10:45:45 am Daniel Kolbo wrote: > Hello PHPers, > > This is a two part question: > > 1) Is it faster to include one file with lots of code, or many separate > smaller individual files? Assume the one massive file is merely the > concatenation of all the smaller individual files. (I am assuming the > one massive file would be faster..., but i wanted to get confirmation). Conventional wisdom is that the one big file is faster, since it requires one disk I/O hit instead of several. HOWEVER, if you're only using a small portion of that code then it could be faster to load only the code you really need. Where the trade off is varies with your architecture, the amount of code, ad how good the disk caching of your OS is. > 2) Suppose php has to invoke the include function 100 times. Suppose > all files are on average the same size and contain the same number of > instructions. Would it be faster to include the same exact file 100 > times as opposed to 100 different file names? Basically, does the > engine/parser take any shortcuts if it notices that the file name has > already been included once? I'm pretty sure that PHP will recognize that it's already parsed that file and keep the opcode caches in memory, so it needn't hit disk again. I've not checked into that part of the engine, though, so I may be wrong there. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OOP Design Question
On Sunday 20 December 2009 10:35:56 am Daniel Kolbo wrote: > Hello PHPers, > > I have a collection of about 60 objects (class definitions). They are > all very similar. They all share a substantial % of the same core. But > they all have slight variations as well. The approach I took was to > make an abstract core class, and each of the 60 objects extends that > core. This works, but... > > Here's my problem, not every php/http request requires all 60 objects. > At this point, I do not know in advance which objects will be required, > so i include the class def of all 60 objects every time... I don't like > this idea as it seems a 'bloated' approach. > > So now i'm thinking instead i'll just have one object which has the > union of all the 60 objects' methods. But i'm not too happy with this > either b/c (i) now each instantiated object is carrying around a lot of > unneccessary baggage, (ii) i lose modularity of code, and (iii) the code > does not make as much 'intuitive' sense. For (iii), 'why does this > object have this method?' type questions another programmer would ask > (or me a year from now). The answer would be 'efficiency concerns', > which i'm aware that you generally don't want to compromise code > readability for efficiency if avoidable. > > Maybe this would be the perfect opportunity for the php autoload > functions...? > > Thanks for your help/thoughts/comments, > dK > ` Yep, this is a textbook case for a proper autoload setup. And no, cramming all of the functionality into one mega class won't get you any efficiency. In fact, it would be just as wasteful as loading all 60 classes even when you're only going to use 2; you're still loading up roughly the same amount of code. Parsing it as one mega class or one big parent with a few small child classes is about a break-even as far as performance goes, but the mega class is much poorer architecture. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Good SQL builder class
I actually spent a great deal of time trying to make purely array based query builders, and came to the conclusion that it's not possible to make a really robust one. However, you can do it with OO and arrays. Have a look at Drupal 7 (current development version of the Drupal CMS). It includes a new DB layer totally rewritten to use PDO and includes a series of robust SQL builders. It's also really easy to separate from Drupal; you need to comment out 2, perhaps 3 lines of code total. At some point I want to spin it off as a stand-alone project, but for now it's easy to rip out. In fact it's already been ripped out and backported to Drupal 6, so you can grab the code from there (GPL) and tweak as needed. http://drupal.org/project/dbtng On Friday 04 December 2009 7:09:55 am Anton Heuschen wrote: > Good day. > > I'm looking for a good class to handle building dynamically from and > array (and if it is good it will automatically determine / or even > have different methods) to handle mutli-dimensional arrays or simple > associative arrays ... and build the SQL statement : > > for example I have an array : > > $home[$suburb]["street"] = test1; > $home[$suburb]["housenr"] =2; > > > Ok to keep it simple to 2, then I want to build the SQL like > > insert into homes (STREET, HOUSENR) VALUES ($val1,$val2); > > > something like that, but I could also pass some array like : > > $home["street"] = test2; > $home["housenr"] = 2; > > > but the idea stays the same = the index is the name of the DB fields > and the assigned value the element > > > > I have looked on hotscripts and phpclasses but I have no idea how good > the solutions are that I have found thus far - therefor need some > recommendation from someone else past experience of this -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Classes and Functions
On Sunday 01 November 2009 2:50:55 pm Daniel Kolbo wrote: > Hello, > > Is there a way to see what objects and functions a script > loaded/required/used? > > I could recursively loop through the globals, but if objects were unset, > then i may miss some. > > I could make a 'tracking' object and every time i load/include a file > (which contains a class def or a function def) to add that file to the > tracking object...but it would be nice if i didn't have to modify my > existing code to see which objects and functions a script actually used, > or at least, requested and loaded into memory. > > Thanks in advance, > Daniel Kolbo > ` Depends what you are trying to do with it, but I suspect these are a good start: http://www.php.net/get_defined_functions http://www.php.net/get_defined_vars http://www.php.net/get_defined_constants http://www.php.net/get_declared_classes http://www.php.net/get_declared_interfaces http://www.php.net/get_included_files -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php exception handling
On Sunday 11 October 2009 6:09:46 pm Tommy Pham wrote:
> Lars,
>
> Here's a pseudo code:
>
> try {
> if (!$valid) {
> throw new Exception("Test failed.");
> } else {
>// do something
> }
> } catch (Exception $e) {
> // set/print a user friendly message to send to output
>
> // set a detailed message using debug_backtrace() or any other
> information relevant for easier troubleshooting // log and/or email
> detailed message
> }
>
> Regards,
> Tommy
Actually the else clause is not necessary. That's one of the nice things
about exceptions. If you throw an exception, processing jumps to the
appropriate catch and never returns.
try {
// Do normal stuff.
if (!$valid) {
throw new Exception('OMG!');
}
// Do more normal stuff.
}
catch (Exception $e) {
// Print user friendly message.
// Log detailed information or whatever you're going to do.
}
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP programming strategy
On Saturday 01 August 2009 11:01:11 pm Eddie Drapkin wrote: > > I actually benchmarked that once. I had a reasonably large PHP file that > > was, in fact, over 50% docblocks. That's not even counting inline > > comments. While trying to find things to optimize, removing about 800 > > lines worth of comments (all of the docblocks) did, in fact, produce a > > noticeable performance difference. It was only barely noticeable, but it > > just barely registered as more than random sampling jitter. I actually > > concluded that if cutting the file *in half* was only just barely > > noticeable, then it really wasn't worth the effort. > > Yeah but what happens if you run the script through the tokenizer and > strip ALL comments, unnecessary whitespace, newline characters, etc. > out? Honestly? I think you'll save more CPU time by eliminating one SQL query. Most files are not 60% comments. In a file that is only about 20% comments, I doubt you could even measure the difference. There are far far far more useful ways to optimize your code. (Note that this is different for CSS or Javascript, where compressors like that are commonplace because you have to transfer the entire file over the network repeatedly, which is a few orders of magnitude slower than system memory. Compressors and aggregators there make sense. PHP code never leaves the server, so those benefits don't exist.) -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP programming strategy
On Saturday 01 August 2009 8:25:40 pm Clancy wrote: > Is anyone here interested in discussing programming strategy, or or know of > a discussion group which is interested in the subject? > > The sorts of questions I am interested in are: > > 1. I have a highly variable program which always shows the same page, but > which includes different modules to give different results. The various > modules call on different functions. Is it better to minimise memory by > including only the functions actually required, but increase the number of > files included, or to bundle all the functions into one file, thereby > reducing the number of files included but increasing the size in memory? That depends greatly on your usage patterns. Does your application make lots of "sideways" calls to integrate different modules, or is just "switch on a GET parameter, run this function, done"? If the latter, then lazy-loading just the one or two files you want is probably better. If the former, you'd need a lot of interesting logic to make lazy-loading work well enough to be justified. (I've been working on such a system for Drupal for the past year, and it's not easy to get right because there can be a fair bit of overhead.) If your application is heavily OOP then PHP supports dynamic autoloading of classes, which can greatly simplify your code logic but at the same time the autoload mechanism itself is not free either. The age of the computer matters, too. Modern hard drives are faster than they used to be, and more recent OS versions can do some fairly aggressive caching if the files you're reading all fit inside the OS cache somewhere in memory so you may not actually hit disk to "load" each of your files. > 2. As PHP is an interpreted program comments certainly increase the memory > requirements, and presumably they slow down the operation of the program. > Would stripping out the comments before uploading the production version > give any visible improvement in performance? I actually benchmarked that once. I had a reasonably large PHP file that was, in fact, over 50% docblocks. That's not even counting inline comments. While trying to find things to optimize, removing about 800 lines worth of comments (all of the docblocks) did, in fact, produce a noticeable performance difference. It was only barely noticeable, but it just barely registered as more than random sampling jitter. I actually concluded that if cutting the file *in half* was only just barely noticeable, then it really wasn't worth the effort. Just install an opcode cache. That will take care of most of your memory issues. :-) -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php applications
On Monday 08 June 2009 12:34:40 pm Robert Cummings wrote: > Matty Sarro wrote: > > Real men use perl ;) > > When I was younger my dad told me real men drink their coffee black... I > tried it for a month and then I told him real men choose their own path > in life. > > Cheers, > Rob. Mind if I use that quote elsewhere (credited if you prefer)? -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web application design considerations - a good reference ?
Do not under any circumstances try to do this from scratch. :-) Use an existing framework like Zend Framework or CakePHP or a CMS/framework hybrid like Drupal or a dedicated app for billing and processing. It will save you months of work, and countless security holes. Even if you don't use it directly, studying a large existing system like that will open your mind to better ways of thinking. I only half-joke when I say that everything I know about PHP I learned from Drupal. :-) On Monday 01 June 2009 11:50:36 pm Angus Mann wrote: > Hi all. > > I'm working on a PHP project for my own personal business use. It will > handle billing and invoices as well as payments and time management, > bookings, appointments and a few more. I may add things like personal > messaging between the various users and a customer login to check on the > progress of their accounts. > > It is a big project and will probably take a year or so to complete in my > spare time. > > I have made a couple of starts but I have no experience in creating such > large applications and I find I often end up with spaghetti code. I've > tried using session variables to keep track of where and what the program > is doing but there are so many permuations and combinations I found myself > writing endless streams of if's, and's and or's just to figure out what > page to display. > > The code is not the probblem for me...it's the flow and organization of the > code. > > Can anybody point me to a good book or tutorial that lays down the > principles and gives some suggestions for integrating the many subroutines > of a large application? I want to make the code readable and logical in its > flow, and avoid repetition of code segments. > > Much appreciated. > Angus -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP6 return by reference deprecation
On Saturday 02 May 2009 3:20:24 pm Colin Guthrie wrote:
> 'Twas brillig, and Larry Garfield at 02/05/09 20:00 did gyre and gimble:
> > On Saturday 02 May 2009 9:30:09 am Colin Guthrie wrote:
> >> 'Twas brillig, and Paul M Foster at 02/05/09 06:07 did gyre and gimble:
> >>> If this is going away, how do you return things by reference, so as to
> >>> ensure a single copy of something (yes, I know the singleton pattern
> >>> can be used; I do use it as well; it's more complicated)?
> >>
> >> You'll want to use the Singleton design pattern here.
> >>
> >> Let's say you're config object is a class.
> >
> > That's well and good if the thing you want a single copy of is an object.
> > The way objects pass in PHP 5 makes singletons easy. But I actually
> > just developed a system for PHP 5.2 that includes a class that
> > deliberately allows a caller to reach in and grab an internal array-based
> > data structure for special cases.
> >
> > class Foo {
> > protected $internalConfig = array(...);
> >
> > public function &getConfig() {
> > return $this->internalConfig;
> > }
> > }
> >
> > $foo = new Foo();
> > ...
> > $config = &$foo->getConfig();
> > // Do stuff to $config that wouldn't make sense to do via methods.
> >
> > So do I understand the OP correctly that is going to break with PHP 6
> > now? I certainly hope not, as that would be incredibly short sighted and
> > stupid. There are plenty of use cases for returning by reference besides
> > making PHP 4 objects behave correctly.
>
> Use ArrayObject rather than just array. e.g.
>
> class Foo {
>protected $internalConfig;
>
>public function __construct() {
> $this->internalConfig = new ArrayObject(...);
>}
>
>public function getConfig() {
> return $this->internalConfig;
>}
> }
>
> http://www.php.net/manual/en/class.arrayobject.php
>
> Col
If it were just a simple one level array, sure. But it's not. It's actually
quite deep and complex. (That's why exposing it is a better plan than just
offering an accessor.)
ArrayAccess is also dramatically slower than regular arrays:
http://www.garfieldtech.com/blog/magic-benchmarks
So forcing everything through an object is still pointless and a performance
loss.
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP6 return by reference deprecation
On Saturday 02 May 2009 9:30:09 am Colin Guthrie wrote:
> 'Twas brillig, and Paul M Foster at 02/05/09 06:07 did gyre and gimble:
> > If this is going away, how do you return things by reference, so as to
> > ensure a single copy of something (yes, I know the singleton pattern can
> > be used; I do use it as well; it's more complicated)?
>
> You'll want to use the Singleton design pattern here.
>
> Let's say you're config object is a class.
That's well and good if the thing you want a single copy of is an object. The
way objects pass in PHP 5 makes singletons easy. But I actually just
developed a system for PHP 5.2 that includes a class that deliberately allows
a caller to reach in and grab an internal array-based data structure for
special cases.
class Foo {
protected $internalConfig = array(...);
public function &getConfig() {
return $this->internalConfig;
}
}
$foo = new Foo();
...
$config = &$foo->getConfig();
// Do stuff to $config that wouldn't make sense to do via methods.
So do I understand the OP correctly that is going to break with PHP 6 now? I
certainly hope not, as that would be incredibly short sighted and stupid.
There are plenty of use cases for returning by reference besides making PHP 4
objects behave correctly.
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Too many open files
I've a site on a shared host that is for the most part working well. However, more recently I've started getting the following error: failed to open stream: Too many open files in system in on line . When it happens it will happen to everyone for a short period, and then stop. There does not seem to be much if any functionality failure when that error appears (I am just seeing the error in my application logs so I can't be sure), but it is still highly annoying and worrisome. The number of files used by my application has not changed in months, however. I know PHP has a max-files-open limit somewhere. Is that per process, per user, or per server? Is this even something I can address myself in my app, or does it indicate that the server itself is getting over-busy and I have to just beg my web host for a less busy server? Any other thoughts as to how to respond? Cheers. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP includes
On Monday 09 March 2009 3:07:17 pm Nathan Rixham wrote: > Ashley Sheridan wrote: > > Just thought I'd point out that it's recommended against giving non-php > > extensions to PHP code pages. Basically, making all of your include > > files .inc without the server correctly configured to recognise all .inc > > files as PHP files, you are opening yourself up to possible hacks where > > people put the URL of your include directly in their browser and view > > all your code. Best thing is usually to name files like this: > > filename.inc.php or some-such, and not filename.inc. > > v well said - one thing you never want is your source showing! Unless you're working in open source and then the source is showing anyway from the original download site. And if simply knowing your source code is a security hole, then you have bad software. Your config file with passwords and such, sure, keep that locked down tight. But don't rely on security through obscurity. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP OOP
On Monday 09 February 2009 10:02:37 am tedd wrote: > Hi gang: > > At the college where I teach, they are considering teaching OOP, but > they don't want to settle on a specific language. > > My thoughts are it's difficult to teach OOP without a language -- > while the general concepts of OOP are interesting, people need to see > how concepts are applied to understand how they work -- thus I think > a specific language is required > > I lean toward C++ because I wrote in it for a few years AND C++ > appears to be the most common, widespread, and popular OOP language. > > However, while I don't know PHP OOP, I am open to considering it > because of the proliferation of web based applications. My personal > opinion is that's where all programming is headed anyway, but that's > just my opinion. > > With that said, what's the differences and advantages/disadvantages > between C++ and PHP OOP? > > Cheers, > > tedd I definitely agree that teaching OOP without a language to write it in is a very stupid idea. However, part of the problem is that there is in practice no one version of OOP. Java is probably the best example of academically pure "classic OOP" (that is, class-based). That can be good for teaching, but it can also suck for developing because you have to do things in an academically formal way. Javascript, on the other hand, is a prototype-based language. Technically that's also OOP, or can be, but the code is entirely different conceptually when functions, methods, objects, and classes are all the same thing. :-) PHP's OOP is very closely modeled on Java's, but with some interesting additions. PHP 5.3 adds a few more and 5.4/6.0 is likely to add traits, which are another animal entirely. PHP is also a hybrid language and, by nature of being a shared-nothing scripting language OOP is often the wrong choice because of the setup and initialization costs. C++ has "a little of each", albeit in a frequently convoluted way. It also has about 30 more types of access control than any other language I know, for better or worse. LISP is its own creature, closer to Javascript than to anything else I just mentioned. (Or arguably Javascript is closer to LISP.) Personally, I recommend teaching programming first in C++. Force them to do the hard stuff so they appreciate what the runtime is doing for them in higher level languages. It also means you can teach procedural and OOP in the same syntax. Then once they've gotten a few bruises in C++, expose them to Java, Javascript, PHP, etc. to let them see what higher level work actually gets done in these days. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] DB Comparisons
On Thu, 05 Feb 2009 12:36:02 -0800, revDAVE wrote: > Hi Folks, > > I¹m curious if there are any previous discussions / Articles / URL¹s > that > compare the power and scalability of MySQL (with php) with other > technologies like MS sequel server oracle - coldfusion etc > > I imagine that most middleware like php / asp / coldfusion is relatively > good & fast - (let me know if one is better ). Mostly I¹m concerned with > the speed and power of the backend database as to how it functions on an > enterprise scale such as how many hits it can handle per hour how > many > users before it starts to slow down etc. 1) Define "enterprise scale". The word "enterprise" has no useful meaning other than "your software isn't ready for it, therefore you suck". :-) 2) How well do you know your DB? A well-tuned MySQL database will blow the crap out of a default config PostgreSQL server, but a well-tuned PostgreSQL server will wipe the floor with a badly configured mySQL database. Your knowledge of the underlying tool and how to get the most out of it will matter more than which vendor you go with, unless there are very specific features you require. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Enclosing Tags? Do You Close Your PHP Declarations?
On Mon, 2 Feb 2009 08:23:49 +0100, Yannick Mortier wrote: > 2009/2/2 Alpár Török : >> >> >> 2009/2/1 Yannick Mortier >>> >>> I once read that this is even recommended by the PHP developers... Has >>> anyone got a quote for me about this? >>> >> >> I know thw ZF codinf style includes it as a must. See here : >> >> > http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html#coding-standard.php-file-formatting.general The Drupal coding standards say to exclude the closing ?> on files for the same reason: It avoids a host of problems with whitespace handling and is just one less thing to have to deal with. http://drupal.org/coding-standards --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Content Management
On Friday 30 January 2009 12:16:44 am Jason Todd Slack-Moehrle wrote: > Hi All, > > I am looking for an open-sourced CMS that is PHP/MySQL based. > > I would like something simple to setup, but also would be good for a > storefront as I want to use it for my indie business. > > Thoughts? > > -Jason http://drupal.org/ I freely admit that the initial learning curve is a bit higher than we'd like, but you can still get very far without any PHP coding. A custom look and feel unique to your site will, of course, require making a custom theme but if you're good with CSS that won't require much if any PHP either. The payoff for the initial learning curve is a system that will scale and grow with you and your business almost indefinitely. The community around it is also extremely supportive and there's a plethora of options for commercial development and support as well if you are so inclined. For e-commerce, check out the "Ubercart" suite of modules: http://drupal.org/project/ubercart Disclaimer: I am a Drupal core developer and build sites with it professionally, so I am hardly an unbiased source. :-) -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Doc standard for methods?
Greetings, all. I am looking for feedback on a documentation question, in the
hopes that someone else has found a good solution to an abnormal situation.
We're in the process of introducing OOP syntax to a large procedural code
base. Our developer base is a mixture of people who are procedural-centric
and those that flip between procedural and OOP easily. One area we've run into
is documenting some of the more complex OOP interactions. For example, if we
have a method chain:
foo()->bar()->baz()->narf();
some developers have expressed concern in figuring out which narf() method is
actually being called, since foo(), bar() and baz() may return objects of
different classes (of the same interface) depending on various conditions (the
classic factory pattern).
Currently, we're including a docblock (Doxygen, close enough to PHPDoc for
government work) on the interface or parent class that has full docs, and then
nothing on the child classes. My understanding of docblocks is that most
documentation parsers prefer that, so that the docblock itself inherits.
One suggestion that has been raised is to reference the parent class and
factory function in a comment after the method signature. That is:
class Narfing_mysql {
// ...
public function narf() { // Narfing foo()
// ...
}
}
So that it can be easily grepped for. That strikes me as a very hacky non-
solution. Does anyone else have a recommendation for how to improve such
documentation? Is there a standard in PHPDoc that I don't know about? Any
other projects doing something like that?
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] old HTTP variables
On Sunday 18 January 2009 11:12:28 pm Ashley M. Kirchner wrote: > Maybe I'm asking for trouble here, but, is there any way to make PHP > 5.2.8 understand the old $HTTP variables? Like: > > $HTTP_SESSION_VARS > $HTTP_GET_VARS > $HTTP_POST_VARS > $HTTP_SESSION_VARS > $HTTP_COOKIE_VARS > > etc., etc. > > I have an old application for which development has stopped back in > 2004 ... Should I give up now and install an earlier version of PHP > (and somehow have it behave nice next to PHP5? > > -- A http://us3.php.net/manual/en/ini.core.php#ini.register-long-arrays Although you should probably take the time to upgrade the app anyway, as those variables are deprecated and won't be around forever. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Thank you everyone, What a wonderful world
On Saturday 03 January 2009 1:17:07 pm Dotan Cohen wrote: > 2009/1/3 Behzad : > > since you have modern weapons, equipped > > with lasers! > > Did somebody say sharks with frigin' lasers? No, but we have some ill-tempered sea-bass. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Problem with fetching values...
On Monday 29 December 2008 2:26:46 am Michelle Konzack wrote: > Am 2008-12-28 16:11:15, schrieb Nathan Nobbe: > > OK. i would stop right there and ask yourself why.. there are tons of > > stable, working solutions out there that already do this, most notably > > for php5, PDO, > > > > http://us.php.net/manual/en/pdo.drivers.php > > > > which btw, is written in C ;) > > I have tried to test it... > > The problem is now, that none of my 4 Hosting provider support it. :-/ Then you seriously need new hosting providers. PDO is part of the standard install for PHP5, and there is simply no excuse for a web host to not support it. You can try contacting them first to ask them to enable it, and if they say no, you say "go away". Really, that's simply irresponsible on their part. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Architecture patterns in PHP
On Saturday 27 December 2008 6:57:18 pm Murray wrote: > I'm interested in this topic as well. I'm starting out on a reasonably > large web application, and I'm wondering at the best approach in PHP, > particularly since it's been some years since I worked with PHP on a daily > basis (the last 5 years have been purely C#). > > There's some dev community bias against using frameworks, isn't there? On > one hand I'd love to take an approach that would make my end goal easier > (thanks for pointing out Code Igniter, I'll look into it further), but on > the other hand I'd rather avoid choices that 'tainted' (perhaps not the > right word, but the best I could think of) the overall acceptance of the > application once it's ready for release. > > So, currently I'm wondering about things like, 'Do I make an app that is a > distinct page-per-function, or do I make an app that uses a monolithic > index.php (similar to Wordpress?) and dynamically presents > *everything*based on querystring values.' > > M is for Murray There are exactly 47 architectural patterns, not a single more or less. And if you believe that, I have a bridge you may be interested in. :-) Seriously though, you'll probably find an existing implementation of any architectural pattern in PHP, including the ones that have absolutely no business being implemented in PHP. (I include MVC in that, actually[1].) If you really want to know about OO patterns, pick up the Gang-of-Four book[2] and spend some time wrapping your head around it. (Warning: It is written mostly for a C++ audience, but it's still understandable.) Then ignore those patterns that require more setup effort on each execution than they take to run, as those are ill-suited to PHP's shared-nothing architecture. An active Observer, for instance, really sucks in a web app but a passive observer can do great things. Then, get over your OO biases. :-) PHP can do functions just as well as OO, and because of the setup costs in "proper" OO doing things with functions can often be much faster and require less mental overhead than building out a full OO setup. There are plenty of major projects (PHP and otherwise) that use virtually no OO and still manage to kick ass. (Drupal comes to mind, and the Linux kernel itself is all C code, which doesn't have syntactic OO.) Don't assume that architecture just means OO. Page-per-action vs. a front controller (the index.php to rule them all, usually with mod_rewrite) depends on your app and how you want to extend it. I personally far prefer a front controller approach as it means I can abstract out the bootstrap code and not even have the "include this at the top of every page" stuff. It does mean you want mod_rewrite if your app is going to be at all bookmarkable or googleable (you may or may not want it to be), but that's not a huge requirement. Disclaimer: I was asking this same question about 3-4 years ago, and started looking for PHP systems to study to learn from. I found Drupal, started using it directly, and haven't left yet. :-) That's probably not a bad approach to take. Find an existing system that "feels right" to you and run with that. You'll almost certainly get a better system out of it than trying to write everything yourself. (I've done that before, too, and it was generally a disaster.) [1] http://www.garfieldtech.com/blog/mvc-vs-pac [2] http://en.wikipedia.org/wiki/Gang_of_Four_(software) -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Decorator with public methods
On Saturday 27 December 2008 2:49:22 am Nathan Nobbe wrote: > > Thanks, Nathan. Unfortunately, what you describe is impossible. It > > requires > > me to know all the possible decorators ahead of time and implement the > > interface for each in each decorator, at which point I've gotten no > > benefit at > > all over just putting everything in the original base class in the first > > place. > > That defeats the purpose of decorators if I can't come up with a new one > > a month from now and not have to modify any of the existing code. > > i see it more on a need-to-expose basis. for example, why not, when > presented w/ the current problem, just expose, Baz::doThings() now, b/c you > know you need it in Baz instances ? later if you find theres another > method thats in Bar that isnt yet exposed, you just go in and add a similar > wrapper for it in Baz at that time. this is a typical flow in a layered > architecture in my experience; often times controllers are revised to > expose a new entry point for something on the backend that previously was > unavailble from the front end, just as an example. Because this is for a shipping application, not an in-house app where a month from now I can go back and adjust the interface for every class. (It's open source, but still has a stable release version.) I need to be able to add additional wrapping decorators *without* any modifications to the underlying object or its interfaces. As I said, the interface problem is solvable by having explicit delegating methods in the base decorator class and then only using __call() for nested decorators, which will be a much much smaller portion of the time. It's the performance cost of __call() and the extra call stack layers that are my concern at the moment. -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Decorator with public methods
On Friday 26 December 2008 11:06:07 pm Nathan Nobbe wrote:
> to summarize, using your example above, i would most liely add doThings()
> to Baz, or create another decoration interface for doThings() if you plan
> on using the Bar implementation of doThings() in many places,
>
> interface G {
> function doThings();
> }
>
> class Bar extends Decorator implements G {
> function doThings() {
> // concreate implementation
> }
> }
>
> class Baz implements F, G {
> // recycle Bar::doThings()
> public function doThings() {
> return $this->foo->doThings();
> }
> public function doOtherThings() {}
> }
>
> i appologize if this response is long winded, but im a big fan of the
> decorator, and ive actually got some pretty slick code in production in the
> photobucket code that uses the decorator pattern :D it took about 2 months
> to code, and i leraned a lot about some of the practical aspects of
> decroration, specifically within the realm of php. i know i repeated a few
> things there, but i felt it neccessary to better explain myself.
>
> -nathan
Thanks, Nathan. Unfortunately, what you describe is impossible. It requires
me to know all the possible decorators ahead of time and implement the
interface for each in each decorator, at which point I've gotten no benefit at
all over just putting everything in the original base class in the first place.
That defeats the purpose of decorators if I can't come up with a new one a
month from now and not have to modify any of the existing code.
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Do defined variables exist at application scope, or session scope?
On Friday 26 December 2008 11:54:30 pm Murray wrote: > Hi All, > > In the index.php file of my application I define several variables, > including such things as the base path of the app, and the theme path etc. > > Since I use 'define()' to do this, are these variables available to my app > regardless of where a particular user enters the app? > > So, in starting the app, I define these variables by visiting index.php. > But if another user gets sent a url to, for example, the help page, when > they visit it will those variables be available, or will I need to > explicitly check on each to make sure the variables are defined, because > the user entered at a different entry point than the 'normal' one? > > Note: I will probably do an explicit check anyway, since this seems more > robust, but I ask to better understand how define works. > > Many thanks, > > M is for Murray Well, there is no such thing as a "defined variable". You are, I presume, talking about constants. (That's what you get from define().) A global constant (vis, not a class constant) is "super-global", that is, available absolutely everywhere after the line of code that defines it has executed. So if the user goes to index.php, and the first line defines a constant DEBUG_LEVEL, then that constant now exists anywhere in any function or method for the rest of that page request, period. However, if someone goes to help.php then the line in index.php is never executed (why would it be, since the file was never included?), so the constant is not defined. Does that make sense? -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Decorator with public methods
Excuse me a moment while I delve into complex OO. :-)
I have an object to which I want to add behavior (methods). I cannot use
inheritance here because the object is already of a type or subtype (vis, I am
already using inheritance for something else), and because I want to be able
to add multiple types of behavior at runtime. The normal OO response to this
situation is the Decorator pattern.
interface F {
function doStuff();
}
class Foo {
function doStuff() { ... }
}
class Decorator implements F {
protected $foo;
function __construct(Foo $foo) {
$this->foo = $foo;
}
function doStuff() {
$this->foo->doStuff();
}
}
class Bar extends Decorator {
function doThings() { ... }
}
$f = new Foo();
$b = new Bar($f);
$b->doStuff();
$b->doThings();
OK, great, that's wonderful. You can also nest such decorators indefinitely,
provided that they only override methods from Foo and change its behavior,
then pass on up the chain. Neat. What you cannot do, however, is nest
decorators that have public methods. That is:
class Baz extends Decorator {
function doOtherThings();
}
$f = new Baz(new Bar(new Foo));
$f->doOtherThings(); // Works.
$f->doStuff(); // Works.
$f->doThings(); // Fail.
Now, PHP does have a loophole around this problem in the form of __call().
Specifically, instead of Decorator wrapping each method of F/Foo directly it
implements __call():
class Decorator {
protected $foo;
function __construct(Foo $foo) {
$this->foo = $foo;
}
function __call($method, $args) {
return call_user_func_array(array($this->foo, $method), $args);
}
}
That should work and allow the code snippet above to run, but it has two
significant problems:
1) Because Decorator does not directly implement F, you cannot use type
hinting.
2) __call() and call_user_func_array() are both fairly slow operations, and
stacking them then becomes a nightmare for performance.
#1 can largely be solved by both directly implementing F *and* implementing
__call(), but we're still left with the performance problems of #2. While for
some uses cases that is OK, it can add up to unpleasant microseconds lost.
Can anyone suggest an alternate solution that has less of a performance hit?
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MERRY XMAS
On Tuesday 23 December 2008 9:59:40 pm German Geek wrote:
> Merry xmas to everyone! Thanks for the support and fun discussions.
>
> Regards,
> Tim
foreach ($php_general->subscribers() as $subscriber) {
foreach ($subscriber->holidaysCelebrated() as $holiday) {
print 'Happy '. $holiday->name() .', '. $subscriber->name() .'!'. PHP_EOL;
}
}
--
Larry Garfield
la...@garfieldtech.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Replacing special characters with their HTML equivalents
On Sunday 21 December 2008 5:30:25 pm James Colannino wrote: > Hey everyone. I have a question. I have a web scraper that grabs > information from web pages that often contain characters such as vowels > with umlots (I know I spelled that wrong.) > > The data is editable, so the characters show up unmodified in an > editable text box. However, when I try to import the data into a MySQL > database, the first occurrence of such a character, along with the rest > of the string, is truncated from the result. Not all special characters > cause the problem; vowels with macrons work, for example. > > I don't know if it's failing during the actual query or if the character > is being filtered out at some earlier stage, but whatever the cause, > it's not working. > > My question is, is there a way to replace these characters with their > HTML equivalents? For example, the a with an umlot over the top is > ä in HTML, so before the query is made, and before the filtering on > the string is done, I'd like to replace that special character with its > HTML representation. This allows the user to see the character while > it's in its text box, yet at the same time allow it to be successfully > imported into the database. > > I know about str_replace, but assuming it's the right function for the > job, how would I go about representing these special characters in PHP > so that it will understand what I'm trying to do? > > Thanks! > > James You may find this useful: http://www.garfieldtech.com/blog/unicode-8-vs-16 -- Larry Garfield la...@garfieldtech.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Managed VPS recommendations
On Mon, 10 Nov 2008 11:30:01 -0500, "Daniel P. Brown" <[EMAIL PROTECTED]> wrote: > On Mon, Nov 10, 2008 at 11:09 AM, Larry Garfield <[EMAIL PROTECTED]> > wrote: >> >> So that's a couple of votes for individual people. What company do they > work for? :-) We're not looking for "a guy", we're looking for a firm with > a good reputation. > > Parasane is a whole company, not just me. I'm just the one who > started it back in 2000 but I wouldn't set you up on a VPS anyway. > I began to refuse to sell those in the last few months because > they're more of a scam than anything. "Hey, let's charge the client > the same amount as a fully-dedicated server - if not more - but put > them on a shared box with limited resources." Exciting. :-) Would you offer what we're looking for on a non-VPS basis? As I said, we're not set on a VPS-based solution. We are set on a reasonably priced service that doesn't complain if we ask for SOAP, cURL, and an opcode cache, and doesn't get cranky if we have a big database. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Managed VPS recommendations
On Mon, 10 Nov 2008 09:54:21 -0500, Robert Cummings <[EMAIL PROTECTED]> wrote: > On Mon, 2008-11-10 at 14:26 +0100, Jochem Maas wrote: >> Larry Garfield schreef: >> >> ... >> >> I believe "that guy" Dan Brown might have something up your alley, >> although he might fall over on the 'douchebag' requirement ;-) > >>From Larry's Post: > > "We're looking for a company we can partner with long-term for hosing > several dozen sites." > > Don't do it Dan, he wants to hose several of your sites. Curses, you found me out! > On a more related note :) You may have trouble with VPS system, most > expect you to do your own configuration... that's half the point of a > VPS, you get root access. Of course, since your specs all sound about > the same, you could probably whip up a script that does the update > management for you. > > Cheers, > Rob. Could we? Yes. Do we want to? Absolutely not. :-) For my company, we are very clear with our clients that we do not do server management. If something goes wrong with the server or network routing or anything of the sort, don't talk to us. Talk to the host. For my personal site, it's for an online RPG club where I don't have the time to be a full time sysadmin myself and frankly there's no one else in the club I'd trust anywhere near a root password on any box, let alone the one that runs our whole club. So that's a couple of votes for individual people. What company do they work for? :-) We're not looking for "a guy", we're looking for a firm with a good reputation. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Managed VPS recommendations
OK, so maybe I'm not looking for a VPS per se but I suspect I am given the requirements I have. I am looking for a new web host, both for my personal work and on behalf of my company. (Two separate entities entirely, but odds are I'll end up using the same host for both just to make my life easier.) My specific requirements relate to running medium to large PHP-based web sites. The host we've been using at work is having trouble scaling up nicely, and I want to see what else is out there. Requirements are: - Apache 2 + Must include mod_rewrite, mod_deflate, and other modern tools + Must support at least 2 GB storage per account. - MySQL 5 installed by default. + Must allow databases up to 1 GB in size at least. Larger would be even nicer. + Must support remote database management (tunneled through SSH is OK). + Must allow InnoDB tables; requiring it database-wide and using a different DB server for it is acceptable. - PHP 5.2.3 or better installed by default, including + User-configurable memory limit, up to at least 100 MB. + Respectable set of PHP modules enabled, including SOAP, PDO, SQLite, XML/XSLT, etc. The "modern" tools. + Must be able and willing to install additional PHP modules upon request. + Must be able and willing to configure an opcode cache upon request, or even have it by default. (Here's where I suspect a VPS will be necessary.) - Managed I'm a web developer, not a sysadmin. Installing, configuring, and upgrading the above (such as opcode caches, PHP modules, etc.) must be something the host does, not something they expect me to do. I also don't want to have to go through a multi-week song and dance before the host is convinced to install a common PHP module. (I had to do that to get SOAP support at our current host, and they don't allow us to tweak the memory limit, which is why we're looking elsewhere. A decent control panel is, of course, a must. I admit to not actually liking CPanel or Plesk, as I find them way over-featured and therefore impossible to navigate, but I can probably deal if the host is good otherwise. Naturally a good reputation for not over-selling is also important. It should also be based in the continental USA, but I don't particularly care if they're local. Good corporate citizen track record (e.g., hosts public mirrors) is good icing but not make-or-break as long as they're not douchebags. We're willing to pay for quality, but not be robbed for it. We're looking for a company we can partner with long-term for hosing several dozen sites. So, does this sound like anyone you know? :-) Any hosts you can recommend/avoid? So far random searching has turned up Amazon EC2 and Jaguar VPS as possibilities, but I'd like to get broader input if possible. Thanks all! -- Larry Garfield [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] basic php question...
On Wednesday 05 November 2008 1:20:34 am Yeti wrote: > Do disability browsers support JavaScript? This is not a PHP question, basic or otherwise. However, the answer to your question is "some do, some don't to varying degrees, just to keep life interesting". Search engines, however, do not. So you still need to make sure your site works sans-JS if you want Google to grok it. -- Larry Garfield [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Replacing with f*ck and f*cking
On Sunday 26 October 2008 5:06:09 am Ashley Sheridan wrote: > Obviously, this list could get pretty comprehensive, so like Andrew > said, maybe you should look to see how some of the open source projects > do it. > > > Ash > www.ashleysheridan.co.uk The way Drupal handles such filtering is simple caching. As a policy we never filter general content on save, because we may want to change the filter format later and destroying user-submitted data is *not cool*. However, we do apply a number of possible filters on display (add line breaks, convert URLs to clickable, do "bad word" filtering, or any number of other things) and then just cache the result. The cache lookup (based on a hash of the string being filtered and the ID of the filter set to apply) is far faster than reapplying the filters every time. We've found this mechanism to scale very well. -- Larry Garfield [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Dev Facts
On Thursday 16 October 2008 6:14:18 pm Nathan Rixham wrote: > Evening All, > > I'd be /really/ interested to know who uses what! > > *Procedural or OOP?* Right tool for the job. I'm comfortable in either. Most of my work these days is in a large open source procedural framework, but I'm slowly working more and more OOP into it. :-) > *Dev OS* Kubuntu Hardy. > *Dev PHP Version* 5.2.4 > *Live Server OS* For my personal stuff, hosted FreeBSD. At my company, we use a web host that's running either RHEL or Fedora. (I honestly forget which.) > *Live Server PHP Version* 5.2.6 > *Which HTTP Server Software (+version)?* Apache 2 in most places, but I think a few may be running 1.3 for no good reason. > *IDE / Dev Environment* Zend Studio 5.5 is the only IDE I can actually say I like. More recent versions of Eclipse / Eclipse PDT at least don't suck as much as they used to, which is the only good thing I can say about any of 'em. > *Preferred Framework(s)?* 98% of my PHP is written on, for, and with Drupal. :-) > *Do you Unit Test?* For internal framework stuff (where I can do proper TDD), extensively. For day to day for clients, not all that much. Most of that work is not really unit-testable to begin with, and functional tests are considerably harder to do at this point in Drupal. (Although that is improving.) > *Most Used Internal PHP Class* PDO, probably, since I build the new Drupal DB layer on top of it. However, I am a huge huge fan of ArrayAccess, simply for its cool factor. > *Preferred OS CMS* Drupal (surprise surprise). > *Anything else you use frequently in you're PHP'ing that's worth > mentioning:* Don't underestimate the power of associative arrays. You can get some really deep, really powerful, really fast data structures with a little care and an embracing of associative arrays. > ps: I'm not asking for any kind of research project, just interested and > interested to know what's most common + might learn something/find some > new tools/toys! > > pps: will reply myself as well but if I do here it'll make your > intertwined replies messy! > > Many Regards > > Nathan -- Larry Garfield [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: php framework vs just php?
On Tue, 07 Oct 2008 19:47:54 +0100, Ashley Sheridan <[EMAIL PROTECTED]> wrote: > Don't frameworks introduce a lot more overhead to projects though? > > > Ash > www.ashleysheridan.co.uk Any generic code library adds overhead. How much and whether or not it's acceptable depends on the framework and on your use case. In *most* use cases, PHP execution time is not your bottleneck. Disk IO, database traffic, and network traffic are a much bigger problem. If you can, throw an Opcode cache at it (whether it's a framework or not) to get a nice speed boost. I find I produce much better quality results with much less effort when using a good framework than when writing from scratch. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
