Re: [PHP] Will PHP ever grow up and have threading?
On 23 March 2010 00:02, Daevid Vincent dae...@daevid.com wrote: douche-bags I think this is about the best way to get the wrong attention. Not everyone has a sense of humour like yours. Maybe no one has a sense of humour like yours. Good luck. Richard. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- 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?
Rene Veerman wrote: But i've yet to find a way to keep global objects in memory between http requests, outside $_SESSION, which i believe is just stored to- and loaded from disk between http requests. You can store sessions in a cache and avoid the disk IO. -- 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 Tue, Mar 23, 2010 at 2:04 AM, Per Jessen p...@computer.org wrote: Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) I couldn't agree more. But here's a real life example. Your client has a forum and is using phpbb for their in house use. They also have an in house custom PHP app, integrated with phpbb, built to suit their needs. Now they want to implement some kind of CMS. You come in and implemented a PHP based CMS to integrate into their existing applications. Then you realize something troublesome, you have a performance issue where it could be resolved by implementing thread. What are you going to do? Are you going to say to the client We seem to have a problem. I suggest we migrate to Java or ASP.Net because threading will resolve the performance issue. Or are you going to spend who knows how long to try find a hack to resolve the issue? What do you think the client's response is when their need for the solution requires a short time frame of, if not immediate, implementation? Regards, Tommy -- 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?
Tommy Pham wrote: On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen p...@computer.org wrote: Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) I couldn't agree more. But here's a real life example. Your client has a forum and is using phpbb for their in house use. They also have an in house custom PHP app, integrated with phpbb, built to suit their needs. Now they want to implement some kind of CMS. You come in and implemented a PHP based CMS to integrate into their existing applications. Then you realize something troublesome, you have a performance issue where it could be resolved by implementing thread. What are you going to do? The standard, mature, experienced answer is - buy a bigger box. [snip] What do you think the client's response is when their need for the solution requires a short time frame of, if not immediate, implementation? There are no immediate solutions to immediate performance problems. If you have a poor design that restricts your throughput, you can 1) throw hardware at it or 2) change the design. At some point you'll hit yet another limit with 1), and you are forced back to 2). Somewhere along the line the original designer has presumably left or been made to. /Per -- Per Jessen, Zürich (7.5°C) -- 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 Tue, Mar 23, 2010 at 3:33 PM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen p...@computer.org wrote: Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) I couldn't agree more. But here's a real life example. Your client has a forum and is using phpbb for their in house use. They also have an in house custom PHP app, integrated with phpbb, built to suit their needs. Now they want to implement some kind of CMS. You come in and implemented a PHP based CMS to integrate into their existing applications. Then you realize something troublesome, you have a performance issue where it could be resolved by implementing thread. What are you going to do? The standard, mature, experienced answer is - buy a bigger box. The company started small. As their business grows because they have products services that do not exist in the marketplace, their hardware are already growing along side with it, (load balancers, clusters). So then your solution is buy bigger/more boxes? What if the their server room is filled and already using recent hardware. Their current business needs doesn't need to move to a bigger building. What then? Hire data center's services? What if they want to protect their proprietary break through products and services? What about unnecessary additional total cost of ownership (licenses, power consumption, etc...) for more/bigger boxes, even if they have available space, that could be avoided by just implementing threads? [snip] What do you think the client's response is when their need for the solution requires a short time frame of, if not immediate, implementation? There are no immediate solutions to immediate performance problems. If you have a poor design that restricts your throughput, you can 1) throw hardware at it or 2) change the design. At some point you'll hit yet another limit with 1), and you are forced back to 2). Somewhere along the line the original designer has presumably left or been made to. /Per -- Per Jessen, Zürich (7.5°C) If throwing hardware at it won't work because of the above mentioned, then you would change the design right? How long would that take? What if PHP has threads, how long would it take you implement threads with minor changes versus and overhaul of application design, coding, QA, etc... In summary, you're saying that PHP can not grow/evolve with business right? If the company started small and want to use available open source solutions, then grow quickly because of their unique and quality products and services, and become enterprise level with-in a few years, what then? Slow down business growth just so that IT can migrate everything to another language? Of all the enterprise applications I've seen, they used threads. Regards, Tommy -- 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 3/23/10 6:04 PM, Tommy Pham wrote: If throwing hardware at it won't work because of the above mentioned, then you would change the design right? How long would that take? What if PHP has threads, how long would it take you implement threads with minor changes versus and overhaul of application design, coding, QA, etc... In summary, you're saying that PHP can not grow/evolve with business right? If the company started small and want to use available open source solutions, then grow quickly because of their unique and quality products and services, and become enterprise level with-in a few years, what then? Slow down business growth just so that IT can migrate everything to another language? Of all the enterprise applications I've seen, they used threads. Regards, Tommy The word enterprise is meaningless in this context because it provides no context for the distinction. What does enterprise mean? Gets Captain Kirk to his next date? Is OpenOffice.org's plugin download site enterprise? Is Sony BMG enterprise? The sites for the cities of London and Athens? Whitehouse.gov? That's just a couple of sites now running on Drupal, a particular single-threaded PHP application. That's not counting the thousands of similar organizations running PHP (not even PHP-wrapping-custom-C like Yahoo) applications of various and sundry kinds. (Wikipedia anyone?) PHP *is* in the enterprise and quite happy there. Not ready for the enterprise is a totally meaningless statement. Similarly, if you cannot think of any way to scale an application that doesn't involve threads then I question your competence as a programmer. Sure, threads can be one way to speed things up. There are lots and lots of others that may be more or less appropriate depending on the circumstances. Threads have their own scaling issues, namely they have to live within the same process on the same box. That means when you hit the maximum size of your server, you're done. That doesn't mean threads are bad, but they have their trade-offs just like everything else does. But let's consider what adding threads to PHP would take. That would mean making PHP a shared-memory architecture, so that different requests now operated in the same memory space. That means RAM-based persistence. That means needing to write thread-safe PHP libraries. (Not the ones in C; I mean the millions of lines of code of PHP already out there.) In short, adding threading support to PHP means PHP is no longer PHP. It's Java with dollarsigns. It's a complete and total rewrite of the entire language runtime and environment, and all of the code build atop it. The idea that you could just add threads to PHP and make it enterprise-ready is so naive it's mind boggling. --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?
2010/3/24 Tommy Pham tommy...@gmail.com: On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen p...@computer.org wrote: Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) I couldn't agree more. But here's a real life example. Your client has a forum and is using phpbb for their in house use. They also have an in house custom PHP app, integrated with phpbb, built to suit their needs. Now they want to implement some kind of CMS. You come in and implemented a PHP based CMS to integrate into their existing applications. Then you realize something troublesome, you have a performance issue where it could be resolved by implementing thread. What are you going to do? The standard, mature, experienced answer is - buy a bigger box. The company started small. As their business grows because they have products services that do not exist in the marketplace, their hardware are already growing along side with it, (load balancers, clusters). So then your solution is buy bigger/more boxes? What if the their server room is filled and already using recent hardware. Their current business needs doesn't need to move to a bigger building. What then? Hire data center's services? What if they want to protect their proprietary break through products and services? What about unnecessary additional total cost of ownership (licenses, power consumption, etc...) for more/bigger boxes, even if they have available space, that could be avoided by just implementing threads? That screams poor code design. Then to solve the problem might not be threading or change of language but a reanalyze of the code and the design, probably a re-write. [snip] What do you think the client's response is when their need for the solution requires a short time frame of, if not immediate, implementation? There are no immediate solutions to immediate performance problems. If you have a poor design that restricts your throughput, you can 1) throw hardware at it or 2) change the design. At some point you'll hit yet another limit with 1), and you are forced back to 2). Somewhere along the line the original designer has presumably left or been made to. /Per -- Per Jessen, Zürich (7.5°C) If throwing hardware at it won't work because of the above mentioned, then you would change the design right? How long would that take? What if PHP has threads, how long would it take you implement threads with minor changes versus and overhaul of application design, coding, QA, etc... In summary, you're saying that PHP can not grow/evolve with business right? If the company started small and want to use available open source solutions, then grow quickly because of their unique and quality products and services, and become enterprise level with-in a few years, what then? Slow down business growth just so that IT can migrate everything to another language? Of all the enterprise applications I've seen, they used threads. Same answer as above. Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- MvH / Hans Åhlin Tel: +46761488019 http//www.kronan-net.com/ -- 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?
Tommy Pham wrote: On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen p...@computer.org wrote: Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) I couldn't agree more. But here's a real life example. Your client has a forum and is using phpbb for their in house use. They also have an in house custom PHP app, integrated with phpbb, built to suit their needs. Now they want to implement some kind of CMS. You come in and implemented a PHP based CMS to integrate into their existing applications. Then you realize something troublesome, you have a performance issue where it could be resolved by implementing thread. What are you going to do? The standard, mature, experienced answer is - buy a bigger box. The company started small. As their business grows because they have products services that do not exist in the marketplace, their hardware are already growing along side with it, (load balancers, clusters). So then your solution is buy bigger/more boxes? What if the their server room is filled and already using recent hardware. Their current business needs doesn't need to move to a bigger building. What then? Hire data center's services? Very few companies have a legitimate reason to run their own server room at this point in time and should be using a data center if they are not already. Data centers have excellent bandwidth, diesel generators to keep things live during sustained power outages, temperature control to keep things cool, and often have technicians on hand with spare parts that can take care of many hardware issues 24/7. -- 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?
Let's go back to my 1st e-commerce example. The manufacturers list is about 3,700. The categories is about about 2,400. The products list is right now at 500,000 and expected to be around 750,000. The site is only in English. The store owner wants to expand and be I18n: Chinese, French, German, Korean, Spanish. You see how big and complex that database gets? The store owners want to have this happens when a customer clicks on a category: * show all subcategories for that category, if any * show all products for that category, if any, * show all manufacturers, used as filtering, for that category and subcategories * show price range filter for that category * show features specifications filter for that category * show 10 top sellers for that category and related subcategories * the shopper can then select/deselect any of those filters and ability to sort by manufacturers, prices, user rating, popularity (purchased quantity) * have the ability to switch to another language translation on the fly * from the moment the shopper click on a link, the response time (when web browser saids Done in the status bar) is 5 seconds or less. Preferably 2-3 seconds. Will be using stopwatch for the timer. Now show me a website that meets those requirements and uses PHP, I'll be glad to support your argument about PHP w/o threads :) BTW, this is not even enterprise requirement. I may have another possible project where # products is over 10 million easily. With similar requirements when the user click on category. Do you think this site, which currently isn't, can run on PHP? Regards, Tommy -- 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 Tue, Mar 23, 2010 at 6:17 PM, Tommy Pham tommy...@gmail.com wrote: Let's go back to my 1st e-commerce example. The manufacturers list is about 3,700. The categories is about about 2,400. The products list is right now at 500,000 and expected to be around 750,000. The site is only in English. The store owner wants to expand and be I18n: Chinese, French, German, Korean, Spanish. You see how big and complex that database gets? The store owners want to have this happens when a customer clicks on a category: * show all subcategories for that category, if any * show all products for that category, if any, * show all manufacturers, used as filtering, for that category and subcategories * show price range filter for that category * show features specifications filter for that category * show 10 top sellers for that category and related subcategories forgot to mention: * show 10 random sale specials for that category and subcategories * the shopper can then select/deselect any of those filters and ability to sort by manufacturers, prices, user rating, popularity (purchased quantity) * have the ability to switch to another language translation on the fly * from the moment the shopper click on a link, the response time (when web browser saids Done in the status bar) is 5 seconds or less. Preferably 2-3 seconds. Will be using stopwatch for the timer. Now show me a website that meets those requirements and uses PHP, I'll be glad to support your argument about PHP w/o threads :) BTW, this is not even enterprise requirement. I may have another possible project where # products is over 10 million easily. With similar requirements when the user click on category. Do you think this site, which currently isn't, can run on PHP? Regards, Tommy -- 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?
Tommy Pham wrote: Let's go back to my 1st e-commerce example. The manufacturers list is about 3,700. The categories is about about 2,400. The products list is right now at 500,000 and expected to be around 750,000. The site is only in English. The store owner wants to expand and be I18n: Chinese, French, German, Korean, Spanish. You see how big and complex that database gets? The store owners want to have this happens when a customer clicks on a category: * show all subcategories for that category, if any * show all products for that category, if any, * show all manufacturers, used as filtering, for that category and subcategories * show price range filter for that category * show features specifications filter for that category * show 10 top sellers for that category and related subcategories * the shopper can then select/deselect any of those filters and ability to sort by manufacturers, prices, user rating, popularity (purchased quantity) * have the ability to switch to another language translation on the fly * from the moment the shopper click on a link, the response time (when web browser saids Done in the status bar) is 5 seconds or less. Preferably 2-3 seconds. Will be using stopwatch for the timer. Now show me a website that meets those requirements and uses PHP, I'll be glad to support your argument about PHP w/o threads :) BTW, this I don't currently know a site, sounds like a fun job though. is not even enterprise requirement. I may have another possible project where # products is over 10 million easily. With similar requirements when the user click on category. Do you think this site, which currently isn't, can run on PHP? Yes, I do. There's nothing in your requirements above that sound particularly difficult for PHP to handle with a good design and lots of caching... and of course the right hardware. I think you're hung up on the numbers a bit... those aren't very big numbers for a database. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- 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 Tue, Mar 23, 2010 at 06:17:56PM -0700, Tommy Pham wrote: Let's go back to my 1st e-commerce example. The manufacturers list is about 3,700. The categories is about about 2,400. The products list is right now at 500,000 and expected to be around 750,000. The site is only in English. The store owner wants to expand and be I18n: Chinese, French, German, Korean, Spanish. You see how big and complex that database gets? The store owners want to have this happens when a customer clicks on a category: * show all subcategories for that category, if any * show all products for that category, if any, * show all manufacturers, used as filtering, for that category and subcategories * show price range filter for that category * show features specifications filter for that category * show 10 top sellers for that category and related subcategories * the shopper can then select/deselect any of those filters and ability to sort by manufacturers, prices, user rating, popularity (purchased quantity) * have the ability to switch to another language translation on the fly * from the moment the shopper click on a link, the response time (when web browser saids Done in the status bar) is 5 seconds or less. Preferably 2-3 seconds. Will be using stopwatch for the timer. Now show me a website that meets those requirements and uses PHP, I'll be glad to support your argument about PHP w/o threads :) BTW, this is not even enterprise requirement. I may have another possible project where # products is over 10 million easily. With similar requirements when the user click on category. Do you think this site, which currently isn't, can run on PHP? That strikes me as a pretty stiff target, no matter how you look at it. You effectively want 6 major queries at once, plus response in under 3 seconds on a 75 row product table. I'm not sure I could produce that kind of performance in C at the command line. (I'm sure some smart guy on the list will say he can do it in 2 seconds flat over a 10 Base 2 network with teletypes and acoustic modems.) Which brings me to my question. Why do people expect console-level performance from a web browser? It's kind of rhetorical, since people want everything they can get and more all the time. But if performance came up as a customer question for me, I'd make it clear that they're not going to get console-level performance from a web browser, unless they want to spend a whole lot more money. Neither the world wide web nor browser software were ever designed primarily with speed in mind. The internet is not your local 64-bit 10 gigabyte memory loaded machine. Paul -- Paul M. Foster -- 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 Tue, Mar 23, 2010 at 6:57 PM, Paul M Foster pa...@quillandmouse.com wrote: On Tue, Mar 23, 2010 at 06:17:56PM -0700, Tommy Pham wrote: Let's go back to my 1st e-commerce example. The manufacturers list is about 3,700. The categories is about about 2,400. The products list is right now at 500,000 and expected to be around 750,000. The site is only in English. The store owner wants to expand and be I18n: Chinese, French, German, Korean, Spanish. You see how big and complex that database gets? The store owners want to have this happens when a customer clicks on a category: * show all subcategories for that category, if any * show all products for that category, if any, * show all manufacturers, used as filtering, for that category and subcategories * show price range filter for that category * show features specifications filter for that category * show 10 top sellers for that category and related subcategories * the shopper can then select/deselect any of those filters and ability to sort by manufacturers, prices, user rating, popularity (purchased quantity) * have the ability to switch to another language translation on the fly * from the moment the shopper click on a link, the response time (when web browser saids Done in the status bar) is 5 seconds or less. Preferably 2-3 seconds. Will be using stopwatch for the timer. Now show me a website that meets those requirements and uses PHP, I'll be glad to support your argument about PHP w/o threads :) BTW, this is not even enterprise requirement. I may have another possible project where # products is over 10 million easily. With similar requirements when the user click on category. Do you think this site, which currently isn't, can run on PHP? That strikes me as a pretty stiff target, no matter how you look at it. You effectively want 6 major queries at once, plus response in under 3 seconds on a 75 row product table. I'm not sure I could produce that kind of performance in C at the command line. (I'm sure some smart guy on the list will say he can do it in 2 seconds flat over a 10 Base 2 network with teletypes and acoustic modems.) Which brings me to my question. Why do people expect console-level performance from a web browser? It's kind of rhetorical, since people want everything they can get and more all the time. But if performance came up as a customer question for me, I'd make it clear that they're not going to get console-level performance from a web browser, unless they want to spend a whole lot more money. Neither the world wide web nor browser software were ever designed primarily with speed in mind. The internet is not your local 64-bit 10 gigabyte memory loaded machine. Paul -- Paul M. Foster The response time, max 5 seconds, will be tested on local gigabit LAN to ensure the adequate response (optimized DB code proper hardware) without worrying about users' connection limit and site's upload bandwidth limit (which can easily rectify). Then thereafter will be doing stress test of about 10 concurrent users. As for the major queries, that's where threads come in, IMO, because those queries depend on 1 primary parameter (category ID) and 1 secondary parameter (language ID). This particular site starts with 500 products about 15 categories, without many of those mentioned filters, later grew to its current state. -- 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] Will PHP ever grow up and have threading?
That's okay Larry, YOU don't have to answer. Sorry my post offended you Larry (and anyone else equally offended). ...and yes. I AM angry that they refuse to add functionality to the PHP language that MANY people have been requesting, just because they are stubborn. I'll spare you the links to the threads (no pun intended) as you can easily find them. Have a lovely day! Your best friend always, Daevid. -Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Monday, March 22, 2010 5:39 PM To: php-general@lists.php.net Subject: 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 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) -- 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 20:59:21 Daevid Vincent wrote: That's okay Larry, YOU don't have to answer. Sorry my post offended you Larry (and anyone else equally offended). ...and yes. I AM angry that they refuse to add functionality to the PHP language that MANY people have been requesting, just because they are stubborn. I'll spare you the links to the threads (no pun intended) as you can easily find them. Have a lovely day! Your best friend always, Daevid. -Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Monday, March 22, 2010 5:39 PM To: php-general@lists.php.net Subject: 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 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) You could implement the features yourself. -- Blessings David M. I have been driven to my knees many times by the overwhelming conviction that I had nowhere else to go. -- 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?
David McGlone wrote: On Monday 22 March 2010 20:59:21 Daevid Vincent wrote: That's okay Larry, YOU don't have to answer. Sorry my post offended you Larry (and anyone else equally offended). ...and yes. I AM angry that they refuse to add functionality to the PHP language that MANY people have been requesting, just because they are stubborn. I'll spare you the links to the threads (no pun intended) as you can easily find them. Have a lovely day! Your best friend always, Daevid. -Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Monday, March 22, 2010 5:39 PM To: php-general@lists.php.net Subject: 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 Is this a case of it's too hard? Or is it a case of PHP core developers Subscribe to internals. Read the archives. The truth is out there. just being douche-bags like they are about the whole That's just rude. 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 There are reasons. You would know this if you had done the legwork before opening your mouth and letting crap fall out. 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 PHP is NOT Java. other typed languages) Nor is it OTHER types languages. You could implement the features yourself. Damn, Mr McGlone beat me to it :) When you set the subject line of your rant to something like Will PHP ever 'grow up', I expect your argument to at least be rationale, logical, and quite possibly contain a patch. It's called open source because you too can make changes. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- 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?
It's code design problem you face, there is loots of solutions to use treading in php. (analyse the way ms C# and VB creates and handles threads, and when you have done that you can create a couple of php scripts to acquire the same result). Read GOF (gang of fore) Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2) and PHP 5 Power Programming (ISBN 0-131-47149-X) Start reading and stop being an AHole. 2010/3/23 Daevid Vincent dae...@daevid.com: 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 -- MvH / Hans Åhlin Tel: +46761488019 http//www.kronan-net.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
