Yes they will be implemented. The only extension which might not follow it
is MySQLi because the author refuses to change it :'(
Andi
At 02:51 AM 4/4/2004 +0200, Sabine Seipel wrote:
Hi,
I follow up the the discussion about studlyCaps in ext/mysqli and ext/sqlite
for a while ago. But I missed t
Hi,
I follow up the the discussion about studlyCaps in ext/mysqli and ext/sqlite
for a while ago. But I missed the important posts concerning the conclusion
about this topic.
are studlyCaps will be implemented consequently in mysqli and sqlite
extensions?
thanks in advance!
Sabine Seipel
--
+
Never mind. I checked the source and saw what I was looking for (that the
handler also preserves the object instance and not just the method itself).
I applied your patch. Thanks.
At 11:34 PM 4/3/2004 +0200, Timm Friebe wrote:
On Sat, 2004-04-03 at 21:26, Andi Gutmans wrote:
> In general, I have
On Sat, 2004-04-03 at 21:26, Andi Gutmans wrote:
> In general, I have no problem with adding this consistency.
> Where is a reference to $instance held until the exception occurs?
What kind of reference?
This is what I used to verify the (instance) functionality:
prefix,
get_class($e),
I am in contact with Timm re: integrating his doc into the official manual.
S
Andi Gutmans wrote:
At 08:28 PM 4/3/2004 +0200, Timm Friebe wrote:
Have you contacted the doc guys to make the add this to the PHP manual?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
At 08:28 PM 4/3/2004 +0200, Timm Friebe wrote:
On Sat, 2004-04-03 at 20:00, Jochem Maas wrote:
[...]
> Having read all the posts on studlyCaps on this list, and understanding
> that studlyCaps was the std. for all new OO APIs I found the following a
> little odd:
>
> The documentation at
> http://s
In general, I have no problem with adding this consistency.
Where is a reference to $instance held until the exception occurs? I took a
quick look and couldn't see it but I'm probably missing something.
Andi
At 08:13 PM 4/3/2004 +0200, Timm Friebe wrote:
Hello,
I wanted to check back on the sta
On Sat, 2004-04-03 at 20:00, Jochem Maas wrote:
[...]
> Having read all the posts on studlyCaps on this list, and understanding
> that studlyCaps was the std. for all new OO APIs I found the following a
> little odd:
>
> The documentation at
> http://sitten-polizei.de/php/reflection_api/docs/lan
Hello,
I wanted to check back on the status of my patch to
zend_builtin_functions.c I sent a while ago. It changes
set_exception_handler() to accept the pseudo-type "callable" (instead of
a string referring to a global function).
Examples:
set_exception_handler('function_name');
set_exception
Firstly this is a question rather than an opinion (if anyone wants to
know I prefer studlyCaps for aethetic reasons so I'm happy with the
decision to use them!)
Having read all the posts on studlyCaps on this list, and understanding
that studlyCaps was the std. for all new OO APIs I found the f
It doesn't have to be in the main CVS but it should be in some CVS so that
we can do the necessary tag and know which version went into which PHP
version. It's much cleaner than taking whatever version is placed in some
odd dir on snaps.
Andi
At 06:44 PM 4/3/2004 +0100, Wez Furlong wrote:
I'll
I'll avoid the actual issue here, and just say that keeping tarballs
in our CVS is something to avoid (we can keep them elsewhere and stick
them in our distro if/when appropriate).
--Wez.
> We'd need to have someone who'll maintain this by probably having a stable
> libXML2 tarball someplace in o
At 12:37 PM 4/3/2004 -0500, Ilia Alshanetsky wrote:
On April 3, 2004 12:05 pm, Andi Gutmans wrote:
> We'd need to have someone who'll maintain this by probably having a stable
> libXML2 tarball someplace in our CVS, and then change makedist to create
> the two packages (one with and one without lib
On April 3, 2004 12:05 pm, Andi Gutmans wrote:
> We'd need to have someone who'll maintain this by probably having a stable
> libXML2 tarball someplace in our CVS, and then change makedist to create
> the two packages (one with and one without libXML2). This should make
> everyone happy as long as
At 06:58 PM 4/3/2004 +0200, Andrey Hristov wrote:
Hi internals,
maybe I am late for this for PHP 5 but just want to ask for opinion about
dereferencing indexes of arrays returned by functions. In PHP 5 is
possible to dereference member variables of an objects like :
someFunc()->someMember;
but th
We'd need to have someone who'll maintain this by probably having a stable
libXML2 tarball someplace in our CVS, and then change makedist to create
the two packages (one with and one without libXML2). This should make
everyone happy as long as it's properly maintained.
Andi
At 01:29 PM 4/2/200
Hi internals,
maybe I am late for this for PHP 5 but just want to ask for opinion about dereferencing
indexes of arrays returned by functions. In PHP 5 is possible to dereference member
variables of an objects like :
someFunc()->someMember;
but this :
$b = someFunction()['someIndex'];
is not poss
I think this is an interesting idea. The downside is that __toString()
would need special treatment in the engine (possibly even an extra opcode).
The upside is that people could always use __toString().
Andi
At 03:55 PM 4/2/2004 +1200, Jevon Wright wrote:
Can you add a default __toString() for
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (774 total including feature requests)
===[*General Issues]==
26223 Assigned Error message makes PHP crash (in some special cases)
27372 Verified parse error loadin
19 matches
Mail list logo
