Hi,
Le mardi 18 janvier 2011 à 23:36 +0100, Hannes Landeholm a écrit :
> Just a simple threading
> implementation with a strictly defined way to IPC would be very helpful.
If you just want to throw some executors and pass messages between them
you can already fork processes with pcntl [1] and pas
On Thu, Jan 20, 2011 at 3:25 PM, Martin Scotta wrote:
> and what what happen if the extending class does not call
> parent::__construct() ?
> __construct is just like any other function, but with semantic added on top
> of.
>
> Changing the way it behaves will cause many headaches
What does that
On 20/01/11 23:25, Martin Scotta wrote:
and what what happen if the extending class does not call
parent::__construct() ?
__construct is just like any other function, but with semantic added on top
of.
Changing the way it behaves will cause many headaches
---
BTW, Did you noted that "self" key
Martin Scotta
On Wed, Jan 19, 2011 at 9:19 PM, Stas Malyshev wrote:
> Hi!
>
>
> Many PHP features should be language constructs, but they were made as
>> language hacks.
>>
>> __construct is evil, as like any other language hack
>>
>
> Constructors are standard feature in many languages. There
Hi!
Many PHP features should be language constructs, but they were made as
language hacks.
__construct is evil, as like any other language hack
Constructors are standard feature in many languages. There's nothing
evil in them.
class Client {
function __construct() {
// some
Many PHP features should be language constructs, but they were made as
language hacks.
__construct is evil, as like any other language hack
It does not provides a safe fundation to build safe abstractions, reusable
and extendibles components, which leads to the lack of PHP libraries.
Let's suppo
Hi Sam:
(becomes off-topic here, but for the sake of argument)
On 19 Jan 2011, at 04:14, Sam Vilain wrote:
> On 19/01/11 10:50, Stefan Marr wrote:
>> On 18 Jan 2011, at 22:16, Sam Vilain wrote:
>>> there doesn't seem to
>>> be an interpreter under the sun which has successfully pulled off
>>> th
On 19/01/11 23:10, Sam Vilain wrote:
> On 20/01/11 10:17, Ángel González wrote:
>> Have you taken a look at Runkit_Sandbox? It may provide useful tips.
> *headdesk*
>
> No, I hadn't seen that. Thanks for pointing this out, it looks like
> exactly what I was trying to reinvent...
>
> Cheers,
> Sam.
On 20/01/11 10:17, Ángel González wrote:
> Have you taken a look at Runkit_Sandbox? It may provide useful tips.
*headdesk*
No, I hadn't seen that. Thanks for pointing this out, it looks like
exactly what I was trying to reinvent...
Cheers,
Sam.
--
PHP Internals - PHP Runtime Development Maili
Have you taken a look at Runkit_Sandbox? It may provide useful tips.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
I think the point is that the php language itself does not provide solid
construct for writing rock-solid code. Yes, there are many
programmers/hackers that can, but the effort they put is huge.
I think this is completely untrue.
In Java you are free to extend a class --yours or imported
On 1/19/11 7:50 AM, Pierre Joye wrote:
> Honestly if a given part of an application needs something along this
> line for performance reasons, then doing that on the same box where
> the request is executed may be a bad idea. Tools like gearman will do
> a far better jobs and will let you do resour
hi,
On Wed, Jan 19, 2011 at 4:41 PM, Martin Scotta wrote:
> I think the point is that the php language itself does not provide solid
> construct for writing rock-solid code. Yes, there are many
> programmers/hackers that can, but the effort they put is huge.
Care to enlighten me and tell me what
I think the point is that the php language itself does not provide solid
construct for writing rock-solid code. Yes, there are many
programmers/hackers that can, but the effort they put is huge.
it's so easy to break well-written bug-free code, that's impossible for
developers to share libraries,
On 19/01/11 16:14, Sam Vilain wrote:
> In general, Java's basic types typically correspond with types that can
> be dealt with atomically by processors, or are small enough to be passed
> by value. This already makes things a lot easier.
>
> I've had another reason for the differences explained to
On 19/01/11 3:51 PM, Stas Malyshev wrote:
Hi!
If anything, I would argue that PHP is a language unsuited to beginners (and
other
scripting languages), as it is so flexible it doesn't enforce good programming
practice. Java is much more a 'beginner language' because it has much stricter
Contr
Hi!
like "map" express this well. The idea is that the executor can start
up with no variables in scope, though hopefully shared code segments,
For that you would probably need to put some severe restrictions on your
code, such as:
1. No usage of default properties or statics in classes or
Hi!
If anything, I would argue that PHP is a language unsuited to beginners (and
other
scripting languages), as it is so flexible it doesn't enforce good programming
practice. Java is much more a 'beginner language' because it has much stricter
Contrary to popular belief, people usually don't
Hi!
Yes, I expected the two functions - tsrm_new_interpreter() and
init_executor() to do that, as it is the function called in
php_request_startup() in main/main.c
As far as I remember, you need to run the whole request startup for the
the thread, otherwise there will be unitilialized pieces.
On 19/01/11 10:50, Stefan Marr wrote:
> On 18 Jan 2011, at 22:16, Sam Vilain wrote:
>> there doesn't seem to
>> be an interpreter under the sun which has successfully pulled off
>> threading with shared data.
> Could you explain what you mean with that statement?
>
> Sorry, but that's my topic, and
Strongly second this. PHP is not a toy language restricted to beginners. If it has
advanced features, beginners simply don't need to use them.
If anything, I would argue that PHP is a language unsuited to beginners (and other
scripting languages), as it is so flexible it doesn't enforce good pr
Hello,
I don't think a language becomes a "beginners language" just because many
new programmers use it. And it's still not a good argument for not including
new features.
As long as the new thread doesn't share any memory/variables with the
spawning context, no "reasoning" is required at all. It
Hi!
Sorry, but that's my topic, and the most well know interpreters that
'pulled off' threading with shared data are for Java. The interpreter
Given to what complications Java programmers should go to make their
threaded code work, I have a lot of doubt that 95% of PHP users would be
able to
Hi Sam:
I am following the discussion very interested, but just a question for
clarification:
On 18 Jan 2011, at 22:16, Sam Vilain wrote:
> there doesn't seem to
> be an interpreter under the sun which has successfully pulled off
> threading with shared data.
Could you explain what you mean with
On 18/01/11 22:17, Stas Malyshev wrote:
>> 1) any hints or clues from people familiar with the Zend subsystems -
>> such as memory management, and the various stacks, to provide hints as
>> to how to set them up "correctly"
>
> Zend Engine keeps all state (including memory manager state, etc.)
> se
Hi!
1) any hints or clues from people familiar with the Zend subsystems -
such as memory management, and the various stacks, to provide hints as
to how to set them up "correctly"
Zend Engine keeps all state (including memory manager state, etc.)
separate in each thread, which means once you'v
26 matches
Mail list logo
