On 9/11/07, Pierre [EMAIL PROTECTED] wrote:
On 9/11/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
well, some OSes allow subscribing to the notifications from filesystem
*bsd (including macos-x) use kqueue, linux and winnt have different
mechanisms for the same thing
The question is
On 9/12/07, Alexey Zakhlestin [EMAIL PROTECTED] wrote:
kqueue and friends allow you to skip that TTL part alltogether, as
PHP can just register itself as a subscriber to filesystem events in
related directories. If it notices that the file appeared or
disappeared or changed it can react
On 11/09/2007, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello emo,
Tuesday, September 11, 2007, 4:50:01 PM, you wrote:
I believe I read somewhere that it will look like this:
::class_b-method_c();
This is the preferred way as it doesn't introduce a new keyword. Also this
is inline with
Hello Robert,
yeah ifsetor if much better than the @-?: combination. But for 5.3 that
would be all we could do. For 6 and in the long run we might do a real
ifsetor. If ever we could come to a consensus... and no i don't really like
to restart discussions on ifsetor at this point.
marcus
Marcus Boerger wrote:
I meant %s = [^\n]+?
Ah - I should have guessed that. Yes, it solves the problem, but then
running make test gives an extra 7 failing tests - so I need to look at
why they are failing and work out how to fix them.
and continuing our private discussion earlier we
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
This is a good point - raising errors in chained autoloader
makes little
sense since next one in chain might be able to load the
class. However,
I am still concerned about the performance impact - exhausting all
autoloading
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
14) Link phar extension from PECL into core (possibly enabling it by
default)
-1, we discussed why :) 0 if not enabled by default.
Yes, it was discussed, and I thought it was clear for everybody that phar had
to remain
in pecl and was
W liście LAUPRETRE François z dnia środa, 12 września 2007 12:38:
What do you mean by try both? Could you explain a bit more on that?
Yes. PHK's autoload handler is not filename-based. It works as a (poor
man's :) runtime linker, with a symbol map. In this map, interfaces and
classes have
Paweł Stradomski wrote:
W liście LAUPRETRE François z dnia środa, 12 września 2007 12:38:
What do you mean by try both? Could you explain a bit more on that?
Yes. PHK's autoload handler is not filename-based. It works as a (poor
man's :) runtime linker, with a symbol map. In this map,
From: Pawel Stradomski [mailto:[EMAIL PROTECTED]
B), but what with following language construct:
function doSomething (Service s) {...}
PHP tries to autoload type Service, but it can't know if it's
looking for interface or class. Both are possible.
Correct. I didn't consider this case
Hello LAUPRETRE,
to cut this short. Noone tried to overrule anyone and noone tried to
outsmart or trick in any sense either. In the past we decided on the
following. First it is to early to ring in Phar for a variety of reasons. As
development went on it was more than appropriate for the RM to
Hello LAUPRETRE,
Wednesday, September 12, 2007, 3:32:13 PM, you wrote:
From: Pawel Stradomski [mailto:[EMAIL PROTECTED]
B), but what with following language construct:
function doSomething (Service s) {...}
PHP tries to autoload type Service, but it can't know if it's
looking for
From: Stut [mailto:[EMAIL PROTECTED]
This would need to come from the user implementation of __autoload
through naming conventions or a lookup table. PHP does not
get involved
with resolving a type to a filename, and rightly so.
The question is not to have PHP get involved in the symbol
LAUPRETRE François (P) wrote:
From: Stut [mailto:[EMAIL PROTECTED]
This would need to come from the user implementation of __autoload
through naming conventions or a lookup table. PHP does not
get involved
with resolving a type to a filename, and rightly so.
The question is not to have PHP
W liście Stut z dnia środa, 12 września 2007 15:59:
LAUPRETRE François (P) wrote:
From: Stut [mailto:[EMAIL PROTECTED]
This would need to come from the user implementation of __autoload
through naming conventions or a lookup table. PHP does not
get involved
with resolving a type to a
On Sun, 9 Sep 2007, Ilia Alshanetsky wrote:
1) Backport the namespaces patch for PHP 6
-1
2) Symlink the intl extension from PECL, but leave it disabled by default as
is the case with all extensions dependent on external libs
1
3) Apply the Late Static Binding Patch
1
4) Implement
Translating the documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
I've attached my PHAR variation that was made some time ago
just to prove the concept. It uses standard TAR format and
doesn't use any external libraries.
In case if you call php test.tar.gz, PHP (with this
extension) will execute file
Yes. PHK's autoload handler is not filename-based. It works as a
(poor man's :) runtime linker, with a symbol map. In this map,
interfaces and classes have different symbol types. Today, when this
handler receives a request, it cannot know if it should look for an
interface or a class. So, it has
function doSomething (Service s) {...}
PHP tries to autoload type Service, but it can't know if it's looking
Actually, in this case (and in any case where type of existing object is
checked) autoloading is unnecessary (and it's a bug if it happens) since
if the type Service is not loaded,
W liście Stanislav Malyshev z dnia środa, 12 września 2007:
function doSomething (Service s) {...}
PHP tries to autoload type Service, but it can't know if it's looking
Actually, in this case (and in any case where type of existing object is
checked) autoloading is unnecessary (and it's a
On 9/12/07, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Robert,
yeah ifsetor if much better than the @-?: combination. But for 5.3 that
would be all we could do. For 6 and in the long run we might do a real
ifsetor. If ever we could come to a consensus... and no i don't really
like
to
On Wed, 2007-09-12 at 13:53 -0400, Andrew Shearer wrote:
Here is the patch and unit test file for array_get():
http://ashearer.com/software/array_get/2007-09-10-php6/array_get.diff
http://ashearer.com/software/array_get/2007-09-10-php6/array_get.phpt
And here is the backward
Andrew Shearer wrote:
Meanwhile, array_get() provides the most-needed functionality while avoiding
the issues that prevented ifsetor's acceptance.
Aside from lack of BC hacks what is the issue? I remember some fussing
about the name, but I find this a joke of an argument. You cant get much
Hey Steph,
PECL, right.
Ilia's initial post mentioned possibly enabling them by default
which set off some red flags for me because it's very much alpha.
It'd definitely help things along if it goes into the core, in terms
of exposure / usage / testing.
Best,
Mike Robinson
-Original
Would anyone object to disallowing setting mail.force_extra_parameters
from .htaccess? The problem is that mail.force_extra_parameters can pass
arbitrary arguments to mail tool, and some mail tools (especially one,
guess which ;) have a lot of parameters, that allow, in particular,
reading and
On 9/12/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Would anyone object to disallowing setting mail.force_extra_parameters
from .htaccess? The problem is that mail.force_extra_parameters can pass
arbitrary arguments to mail tool, and some mail tools (especially one,
guess which ;) have a
27 matches
Mail list logo
