Another option which isn't always ideal is to use FastCGI and de-couple Apache
and PHP.
> -Original Message-
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 03, 2007 4:45 PM
> To: Andi Gutmans
> Cc: Nuno Lopes; Pierre; Marcus Boerger; PHP Internals List;
Another possibility: could there be a way to add context information (a
string) to the error message the engine displays? This would alleviate
my concern.
Why not just log it into some logfile? Remember that autoloaders can be
chained, so engine would have to assemble all strings, display them
Andi Gutmans wrote:
> Although it may work for you with your applications unless all of your
> 3rd party libs are compiled with VS 2005 there's a fair chance that
> you'll have issues when data structures are passed between PHP which is
> compiled against one CRT lib to DLLs which were compiled wit
Although it may work for you with your applications unless all of your
3rd party libs are compiled with VS 2005 there's a fair chance that
you'll have issues when data structures are passed between PHP which is
compiled against one CRT lib to DLLs which were compiled with older
versions (different
Stanislav Malyshev wrote:
>> to use die() or some other method of terminating execution. A user
>> calling class_exists() clearly expects a return from autoload, whereas a
>> user instantiating an object will expect a fatal error if the class
>> cannot be found.
>
> This is true, but __autoload sh
Johannes Schlüter wrote:
> The only need I see is mocking objects for a unit test. This is usually
> done on a test system so installing such an extension shouldn't be to
> hard (especially for somebody who is able to do unit tests using mock
> objects...)
This is unnecessary in a well-designed p
to use die() or some other method of terminating execution. A user
calling class_exists() clearly expects a return from autoload, whereas a
user instantiating an object will expect a fatal error if the class
cannot be found.
This is true, but __autoload should never do it, the engine should do
For an extension, which the current implementation is, using the
register function is the best approach I see. Else we would have to to
I would prefer some special function to new handler. This feature has
very narrow use (I still not entirely convinced it even belongs to core
- it's too kludg
I already use 2k3 to compile my binaries or to develop, it works
pretty well. The 2k5 brings more change and require a couple of
important changes in our build (like the manifest support or what
other describe in this thread).
Uhm I use VS 2005 to build PHP (vanila) for quite some time and it wo
import ::Exception AS WTF;
import isn't the means to shuffle standard class names around. Import is
the means to make names shorter. You already have one Exception in
global space, you'd have to use other name for other class.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
should in fact be implicitly importing Blah::Exception as if it were
Foo::Exception, rather than as ::Exception. In other words, I would
actually expect the above code to be equivalent to:
No, not really. It's equivalent to:
There's no class named Foo::Exception and import does not create
Hi,
On Tue, 2007-10-02 at 15:54 +0200, Sebastian Bergmann wrote:
> Guilherme Blanco schrieb:
> > Altho I found this idea really interesting, I have a suggestion for
> > it. Instead of use a function to handle new overloads, I suggest a
> > magic method, something like __new.
>
> __new() was what
On Wed, 2007-10-03 at 15:27 -0500, Greg Beaver wrote:
> I do that now, but it is a severe performance hog as well as being
> fugly. Also, if you use spl_autoload_register, the frame is $bt[2]. In
> other words, it's possible, but still an ugly, unnecessary hack with
> lots of potential pitfalls c
Johannes Schlüter wrote:
> Greg,
>
> On Wed, 2007-10-03 at 15:07 -0500, Greg Beaver wrote:
>> Now what? The error message doesn't tell Joe where to find PEAR2::Foo,
>> or any other useful information on how to find it, just that it can't be
>> found. PEAR2, however, knows exactly where it should
On Wed, 2007-10-03 at 22:23 +0200, Johannes Schlüter wrote:
> Greg,
>
> On Wed, 2007-10-03 at 15:07 -0500, Greg Beaver wrote:
> > Now what? The error message doesn't tell Joe where to find PEAR2::Foo,
> > or any other useful information on how to find it, just that it can't be
> > found. PEAR2,
Greg,
On Wed, 2007-10-03 at 15:07 -0500, Greg Beaver wrote:
> Now what? The error message doesn't tell Joe where to find PEAR2::Foo,
> or any other useful information on how to find it, just that it can't be
> found. PEAR2, however, knows exactly where it should be found, and has
> some idea of
Marcus Boerger wrote:
>> I'd like to avoid my little fatal error trick if the user simply called
>> class_exists('Classname', true) and same for interface_exists(). If I
>> provide a simple patch that would introduce a new HashTable of
>> classnames into EG() called EG(in_class_exists), and a new
LAUPRETRE François (P) wrote:
>>> This way, my autoload handler could simply return if the user is
>>> querying the existence of a class, and die pre-emptively with the
>>> exception I want in other cases where an E_ERROR would result.
>>> This feature would be extremely useful for PEAR2's
>> im
Hi all,
Benjamin has in fact unearthed a bug in the implementation of import.
This code:
should in fact be implicitly importing Blah::Exception as if it were
Foo::Exception, rather than as ::Exception. In other words, I would
actually expect the above code to be equivalent to:
This is a sim
naive question: how do you define your exception which needs to onherit
Exception?
Are you doing this:
class Exception extends ::exception { }
Inside namespace - yes, that's the best way. In fact, I think Exception
extends Exception may work too, but that would be seriously confusing :)
> > This way, my autoload handler could simply return if the user is
> > querying the existence of a class, and die pre-emptively with the
> > exception I want in other cases where an E_ERROR would result.
>
> > This feature would be extremely useful for PEAR2's
> implementation of
> > autolo
Hi internals,
I think you are conentrating on the Exception (and even internal class)
examples a bit too much. Take the following example:
a.php:
b.php:
c.php:
d.php:
Running this example produces a "Fatal error: Import name 'Foo'
conflicts with d
On 10/3/07, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello Pierre,
>
> dropping all vc6 build files seems like a good idea to me.
Only Stan (or Dmitry?) was given them some love lately but the rest of
us use the jscript based build system :). So yes, we can remove them
as well.
> If possible
The exception example is well an exception. Here you must inherit
exception.
That is simply how PHP works, it is an intended limitation. That
said in
this case you should not use Exception for your own stuff. Name it
after
your library or product, like MyProductException.
Hey, i have an
The above code works just fine.
Yes there is a concept. import is best used within a namespace. So,
namespace your code and there is no need to import global classes.
Yep, it works if your whole application uses one namespace, but what
if you have a core package that defines some except
Hello Benjamin,
Wednesday, October 3, 2007, 5:33:21 PM, you wrote:
>>
>> if your exception is so general that it is called exception you can
>> obviously simply use exception.
> Maybe _my_ exception is a generic exception in _my_ framework and
> implements some helper functions i need?
The
if your exception is so general that it is called exception you can
obviously simply use exception.
Maybe _my_ exception is a generic exception in _my_ framework and
implements some helper functions i need? But the discussion is not
about exceptions, it's about classnames that PHP declare
Hello Wietse,
Wednesday, October 3, 2007, 2:35:33 AM, you wrote:
> Changing E_WARNING into E_ERROR causes execution to terminate, as
> one would expect. These and other settings can appear in php.ini,
> on the PHP command line, or they can be made with ini_set() calls
> in the application itsel
Hello Benjamin,
if your exception is so general that it is called exception you can
obviously simply use exception. If your exception is actually doing
something than name that something. Meaning the name of the exception class
is carrying information already. Thus every exception should be spec
Hello Stanislav,
perfectly right :-)
Tuesday, October 2, 2007, 10:21:20 PM, you wrote:
>> But how to know in advance, e.g. think about other libraries, which
>> public classes possibly exist? Isn't this problematic then?
> That should be simple - if you write library using namespaces, no publ
Hello Benjamin,
naive question: how do you define your exception which needs to onherit
Exception?
Are you doing this:
class Exception extends ::exception { }
???
marcus
p.s.: I think that is really ugly and actually sounds like replacing a core
functionality...
Tuesday, October 2, 2007,
Hello Pierre,
dropping all vc6 build files seems like a good idea to me. If possible i'd
like to have vs2002 and vs2003 work as well. And vs2007 is at the door
already.
marcus
Tuesday, October 2, 2007, 1:34:46 PM, you wrote:
> Hi,
> One important thing we forgot to discuss is to drop VS6 sup
Hello Stanislav,
right, we could however change to vs2003 or supply the dependend dlls.
marcus
Tuesday, October 2, 2007, 6:26:47 PM, you wrote:
>> Off the top of your head, what side effects do you already
>> anticipate, specifically? Also, I think Rich makes a good point about
>> the "f
Hello Arne,
yep, those are the tricky parts. I would pea for having final respected.
For private we need to investigate further.
marcus
Wednesday, October 3, 2007, 4:21:40 PM, you wrote:
> On Wed, 2007-10-03 at 07:24 +0200, Sebastian Bergmann wrote:
>> Stanislav Malyshev schrieb:
>> > Thanks,
Hello Stanislav,
new Foo will still return a Foo instance!
marcus
Wednesday, October 3, 2007, 12:00:12 AM, you wrote:
>> Problem is the cost of setting up these, by registering implementations,
>> performing reflection and so on is expensive especially considering the
>> stateless nature of P
Hello Greg,
Tuesday, October 2, 2007, 9:25:22 PM, you wrote:
> Marcus Boerger wrote:
>> Hello Gregory,
>>
>> I don't recall any particular thread but Andi once explained why a few
>> things are instable when exceptions are pending. Some of that is no longer
>> the case so maybe it is time to r
Sebastian Bergmann schrieb:
>> would it be possible to overload final classes?
> Of course. We are not changing the class declaration (compile-time) but
> intercept the object creation (run-time).
I may have been unclear here: a class may pose for a class that contains
final methods. The posing
On Wed, 2007-10-03 at 07:24 +0200, Sebastian Bergmann wrote:
> Stanislav Malyshev schrieb:
> > Thanks, will look at these. I'm extremely uncomfortable with engine
> > change that would allow "new Foo" produce an object that is not Foo.
>
> The restriction
>
>"A class may only pose as one of
Benjamin Schulz wrote:
> On 02.10.2007, at 22:04, Stanislav Malyshev wrote:
>
>
>>> >> import ::Exception as Notused;
>>> import Foo::Exception;
>>> ?>
>>>
>>
>> I wouldn't actually recommend using such code. If you have
>> Foo::Exception just use Foo::Exception - it's short enough :)
>>
>
> And
On 02.10.2007, at 22:04, Stanislav Malyshev wrote:
I wouldn't actually recommend using such code. If you have
Foo::Exception just use Foo::Exception - it's short enough :)
And what if not? "throw App::package::subpackage::Exception" in a
file that has the namespace "App::package::su
Hi internals,
I was asked by Jani to apply for extending my karma rights from my PEAR
right to php-src. (As the form on the website ist just for new users and i
allready have a cvs account with username dsp i do it that way)
greets
David
--
PHP Internals - PHP Runtime Development Mailing List
2007/10/1, Antony Dovgal <[EMAIL PROTECTED]>:
> Yeah, too Perl-ish for me.
=) I dont see the need of implementing this either.
--
http://www.kissofjudas.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
42 matches
Mail list logo
