On 12.11.2009, at 15:27, Ralph Schindler wrote:
There is one key piece of information to keep in mind about this
proposal. This is based on the assumption that all autoloaders need
to do this type of include_path check. I (now) feel this is
questionable concerning that particular use cas
There is one key piece of information to keep in mind about this
proposal. This is based on the assumption that all autoloaders need to
do this type of include_path check. I (now) feel this is questionable
concerning that particular use case.
The best practice should be to only have autoload
On 10.11.2009, at 22:28, Stanislav Malyshev wrote:
Hi!
They dont want to determine if a file exists. They want to be able
to handle the case of a missing file being included differently
than a syntax error. Since php core does not provide such features,
the only
Let's see why they need
On 10.11.2009, at 22:41, Alban wrote:
I think if PHP throws exception instead of warning/error then this
problem will not have existence reason :
sure with exceptions we could provide more contextual information and
also give a local way to handle the situation locally. that being said
f
Le Tue, 10 Nov 2009 21:56:47 +0100, Lukas Kahwe Smith a écrit :
> On 10.11.2009, at 21:31, Stanislav Malyshev wrote:
>
>>> ok .. so your objection to the RFC is solely because it introduces a
>>> new language construct?
>>
>> No, my objection is that it is not necessary to introduce a language
>>
Hi!
They dont want to determine if a file exists. They want to be able to
handle the case of a missing file being included differently than a
syntax error. Since php core does not provide such features, the only
Let's see why they need to handle missing file being included
differently? Or,
On 10.11.2009, at 21:31, Stanislav Malyshev wrote:
ok .. so your objection to the RFC is solely because it introduces
a new language construct?
No, my objection is that it is not necessary to introduce a language
construct, and the construct introduced is not the right one. If
frameworks
Hi!
ok .. so your objection to the RFC is solely because it introduces a new
language construct?
No, my objection is that it is not necessary to introduce a language
construct, and the construct introduced is not the right one. If
frameworks want to find out if file exists or get its name -
On 10.11.2009, at 20:38, Stanislav Malyshev wrote:
there are many approaches to caching, one of which is delete to
invalidate and regenerate before the next use. again as the RFC
makes it clear .. the purpose is to be able to differentiate
between a syntax error and a missing file.
If yo
Hi!
there are many approaches to caching, one of which is delete to
invalidate and regenerate before the next use. again as the RFC makes it
clear .. the purpose is to be able to differentiate between a syntax
error and a missing file.
If you writing your own cache basing on includes, you ca
On 10.11.2009, at 20:07, Stanislav Malyshev wrote:
Hi!
yes that would solve the issue partially. the race condition would
still remain, but its admitedly a rare case .. well I guess not so
rare if you
I would have hard time thinking of application that deletes its own
include files fre
Hi!
yes that would solve the issue partially. the race condition would still
remain, but its admitedly a rare case .. well I guess not so rare if you
I would have hard time thinking of application that deletes its own
include files frequently from other processes and we are supposed to
hand
On 10.11.2009, at 19:49, Stanislav Malyshev wrote:
Hi!
In order to solve the above issues this RFC proposes the addition
of a new
construct/function for now called “autoload_include” for lack of a
better
name that largely behaves like the “include” does today with the
following
differenc
Hi!
In order to solve the above issues this RFC proposes the addition of a new
construct/function for now called “autoload_include” for lack of a better
name that largely behaves like the “include” does today with the following
differences, that when the include failed because of a missing file
> As stated in the RFC, I am not happy with the name "autoload_include".
> Suggestions welcome!
That reminds me of the set theory...
how about:
contain $file;
or
superset $file;
there are also the not so original (as found in many other languages)
keywords "import" / "load".
Best,
~IF.
--
PH
include_silent is the name I though most intuitive once I finished to
read the RFC.
But it may not be the best too. It just need to be verbose.
Cheers,
On Tue, Nov 10, 2009 at 2:45 PM, Lukas Kahwe Smith wrote:
> Ahoi,
>
> I have written an RFC for a more efficient solution to get rid of the com
Ahoi,
I have written an RFC for a more efficient solution to get rid of the
common fopen() hack inside autoloaders:
if ($fp = @fopen($file, 'r', true)) {
fclose($fp);
include $file;
}
Here is the gist of the proposal:
In order to solve the above issues this RFC proposes the addition of a
ne
17 matches
Mail list logo
