On 10/6/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
> Then loader should be able to tell the engine that it shouldn't try
> another handler.
I am not sure, that is a good idea.
Probably, it would be better to allow registering different autoload
functions per-namespace basis?
I think that
Hello Alexey,
that is probably but i wouldn't like it. I think we are going to make it
to complex, to Java like. Keep it simple. The only bad thing is a bit of
a slowdown - eventually - where not loading all classes always by include
isn't slower anyway. That said what we need to solve is th
Hello Larry,
ArrayAccess is not designed to work in any array functions and we
explicitly decided against going that route. We wanted ArrayAccess to
support the array syntax, so [x,y] should be supported if we want that.
However I agree that this kind of slicing is a bit too perlish or
pythonish
Hello Andi,
as far as I heard from from MS that is the much better way anyhow.
marcus
Thursday, October 4, 2007, 5:43:55 AM, you wrote:
> Another option which isn't always ideal is to use FastCGI and de-couple
> Apache and PHP.
>> -Original Message-
>> From: William A. Rowe, Jr. [ma
Hello Andi,
most struct sizes do not matter in the windows API (becasue it takes care
of that). The problem actually lies in the POSIX stuff and the modified
stuff as well as the new *_r() and *_l() and what not functions that do not
exist in the older functions. A thing that hurts first is the
Hello Greg,
I think Johannes has a point here. It is doable in PHP already and you
don't hit a performance issue here as you are showing the message only
when the class is not present. That is just add Johanne' code after you
know that your autoload was responsible but cannot find the class.
ma
I have no love for Perl (and a rather strong dislike of it), but I have to
agree with those who say that "looks like Perl" is a lame reason to reject
something. PHP's object system looks an awful lot like Java, too. That
doesn't make it bad.
"Too unreadable", "not approachable enough", "too
On 06.10.2007 22:38, Larry Garfield wrote:
> I have no love for Perl (and a rather strong dislike of it), but I have to
> agree with those who say that "looks like Perl" is a lame reason to reject
> something. PHP's object system looks an awful lot like Java, too. That
> doesn't make it bad.
I hardly find it too cryptic (it makes some array algorythms much more
readable, actually)
and in this case, having such construction would allow us to implement
array_slice() in userland (which is not true other way round) ;)
On 10/6/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> On 06.10.2007 2
On 06.10.2007 23:57, Alexey Zakhlestin wrote:
> I hardly find it too cryptic (it makes some array algorythms much more
> readable, actually)
Good for you.
> and in this case, having such construction would allow us to implement
> array_slice() in userland (which is not true other way round) ;)
Marcus Boerger wrote:
> Hello Greg,
>
> I think Johannes has a point here. It is doable in PHP already and you
> don't hit a performance issue here as you are showing the message only
> when the class is not present. That is just add Johanne' code after you
> know that your autoload was responsi
Marcus Boerger wrote:
> Hello Alexey,
>
> that is probably but i wouldn't like it. I think we are going to make it
> to complex, to Java like. Keep it simple. The only bad thing is a bit of
> a slowdown - eventually - where not loading all classes always by include
> isn't slower anyway. Tha
Marcus Boerger wrote:
> Hello Andi,
>
> most struct sizes do not matter in the windows API (becasue it takes care
> of that). The problem actually lies in the POSIX stuff and the modified
> stuff as well as the new *_r() and *_l() and what not functions that do not
> exist in the older functions
I am not sure, that is a good idea.
Probably, it would be better to allow registering different autoload
functions per-namespace basis?
Why per-namespace - maybe some applications want it not per-namespace
but per something else? The idea is very simple - you want autoloader
declare that only
1) ability to customize the fatal error message
2) knowing whether the class is required or optional
I don't think we should start customizing error messages. The engine has
a lot of error messages and they are not customized. I see no reason why
autoloader can't produce message of its own if
Stanislav Malyshev wrote:
>> 1) ability to customize the fatal error message
>> 2) knowing whether the class is required or optional
>
> I don't think we should start customizing error messages. The engine
> has a lot of error messages and they are not customized. I see no
> reason why autoloader c
Ever heard of an optional dependency?
Not sure what are you talking about...
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.p
17 matches
Mail list logo
