ExecSum:
* +1 for better threading features in PHP.
* overloading = inheritance?
* listreaders plz allow ppl to vent some frustration without
starting a flamewar.
Threading can be implemented in PHP with an
fopen('http://yourserver.com/url')->fread()_all_threads+usleep(50ms)->fclose()+process
loop.
My own newsscraper threads well like this.
The central script figures out what sites to scrape, and the treaded
subsystem makes sure 1 page per site per N seconds is retrieved.
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.
However, now that i think of it, you could have large pieces of
software stay in memory in a single php script that runs forever and
reads commands (as arrays) out of files (on memory disk?) (put there
by "thread-scripts") and [the "forever running script"] outputs to
stdout, which is caught by the thread-scripts, then passed back to the
thread-caller via fread().
I usually use json for such constructs.
But it's a total hack of course, and i have no idea about performance
issues or even timing bugs. it's "theoretically possible"..
>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
well you could shove all the params in an array, then shove that to
the function called, _or_ a preparatory function that calls the old
function.
as for overloading functions, i think with a bit of cleverness you can
come up with a class / set of functions that simulate overloading of
functions and even inheritance. i for a fact simulate polymorphism
with $functionName_fromPluginX ($params).
i smell all the ingredients that would allow you to overload functions
in php aswell. you'd just have to call things a bit differently,
perhaps like
$var = $overloadingManager->call ('functionName',
'context(object-instance-id)', $param1, $param2).
Better yet; aren't OOP's (and php5's) inheritance features (for
classes) similar to functions overloading? k, it forces you to group
such functions into an object, and derivations into subobjects, but
that's not a show-stopper at all.. You can always ignore the object
boundary and have 1 object-tree for all functions that require
overloading.
& lastly, about the politics of this mail-thread;
imo, it's the ones who "open the counterattack" who start the
flamewar, out of something that is clearly in this case just venting
some frustration with at least partially valid reasons..
imo, it would be wiser to have offered the guy some actual tips and/or
a casual "hey, you could've phrased it friendlier, given the fact that
php costs nothing and all, dude", rather than grabbing the
flamethrower and setting it to vaporize.
On Tue, Mar 23, 2010 at 1:02 AM, Daevid Vincent <daevid@xxxxxxxxxx> 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
