hi,
On Fri, Oct 24, 2008 at 12:55 AM, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> The second release candidate of 5.2.7 was just released for testing and can
> be downloaded here:
>
> http://downloads.php.net/ilia/php-5.2.7RC2.tar.bz2 (md5sum:
> 722b69b8a51050aa25c1e6184e4e8d0e)
>
> The Windows
The second release candidate of 5.2.7 was just released for testing
and can be downloaded here:
http://downloads.php.net/ilia/php-5.2.7RC2.tar.bz2 (md5sum:
722b69b8a51050aa25c1e6184e4e8d0e)
The Windows binaries should become available shortly as well at the
following URL: http://windows.p
Hi!
I notice that 5.3 differs from 5.2 in how array_key_exists treats
objects. In 5.2, if the second parameter (array) is allowed to be object
and HASH_OF is applied to it. However, in 5.3 it would produce a warning
requiring an array if object passed to it. Was it intentional?
Maybe the problem
Stanislav Malyshev wrote:
> Hi!
>
> I notice that 5.3 differs from 5.2 in how array_key_exists treats
> objects. In 5.2, if the second parameter (array) is allowed to be object
> and HASH_OF is applied to it. However, in 5.3 it would produce a warning
> requiring an array if object passed to it. W
Hi!
I notice that 5.3 differs from 5.2 in how array_key_exists treats
objects. In 5.2, if the second parameter (array) is allowed to be object
and HASH_OF is applied to it. However, in 5.3 it would produce a warning
requiring an array if object passed to it. Was it intentional?
Maybe the probl
Johannes Schlüter wrote:
Christian, can you update the patch? - thanks!
I'll give it a try. But I need some help understanding the code.
I don't understand the purpose of the #define constants SAPI_HEADER_ADD
(not the enum value with the same name), SAPI_HEADER_DELETE_ALL and
SAPI_HEADER_SEND
Hi all
As of now (thanks Felipe!) there is a new status option "To be
documented" and quickfix option "Fixed in CVS and needs to be
documented" in our bugtracker.
(Dev) Usage: When fixing bug/feature requests that should be
documented you "close" the report with that quickfix option _and_ fill
g
2008/10/22 Ryan Panning <[EMAIL PROTECTED]>:
> I've been wondering, is such a thing even possible? Is there a good way to
> implement an object destruct order? Here are my thoughts:
>
> In the class definition, specify what "level" of destruction the objects
> should be on. How, I have no idea, I h
I think this should be implemented by user. If you are full OOP in your
application, then just register all your objects in some global object (In
my case I have a global singelton) and trigger hiv removal at the end of
your application. If you have destructors written in every object - they
will b
Jani Taskinen wrote:
Nathan Rixham wrote:
just to add it in; in ejb3 in java you have PostConstruct and
PreDestroy which are pretty useful; maybe something along the same
lines could be implemented in PHP?
Or perhaps you should just stick with Java?
just a suggestion for some useful func
Nathan Rixham wrote:
Diogo Galvão wrote:
"The destructor method will be called as soon as all references to a
particular object are removed or when the object is explicitly destroyed
or in any order in shutdown sequence."
As far as I understand it if your active record references the PDO
instan
Diogo Galvão wrote:
"The destructor method will be called as soon as all references to a
particular object are removed or when the object is explicitly destroyed
or in any order in shutdown sequence."
As far as I understand it if your active record references the PDO
instance (say $this->conn) y
"The destructor method will be called as soon as all references to a
particular object are removed or when the object is explicitly destroyed
or in any order in shutdown sequence."
As far as I understand it if your active record references the PDO
instance (say $this->conn) your object gets destr
On Thu, Oct 23, 2008 at 12:26, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> Hannes Magnusson wrote:
>>
>> On Thu, Oct 23, 2008 at 11:51, Jani Taskinen <[EMAIL PROTECTED]> wrote:
>>>
>>> 2. You can always simply put a short comment like "Fixed in CVS, needs
>>> documenting" and reclassify the bug repo
Hello Ryan,
during 5.0 alpha phase I had that actually implemented. But it turned
out to be too much of a slowdown and also could not solve all dependency
graphs. For example you can obviously not solve dependency cycles. So at
the end of the experiement we decided against it.
Maybe we could im
Hannes Magnusson wrote:
On Thu, Oct 23, 2008 at 11:51, Jani Taskinen <[EMAIL PROTECTED]> wrote:
2. You can always simply put a short comment like "Fixed in CVS, needs
documenting" and reclassify the bug report as docu issue. There's no need
for some fancy shortcuts or such. Just tune your proces
On Thu, Oct 23, 2008 at 11:51, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> 2. You can always simply put a short comment like "Fixed in CVS, needs
> documenting" and reclassify the bug report as docu issue. There's no need
> for some fancy shortcuts or such. Just tune your process..
Well, or use the
Jani Taskinen wrote:
1. This should be applied to PHP_5_2 (not big change and in no way can
break anything)
2. You can always simply put a short comment like "Fixed in CVS, needs
documenting" and reclassify the bug report as docu issue. There's no
need for some fancy shortcuts or such. Just t
1. This should be applied to PHP_5_2 (not big change and in no way can
break anything)
2. You can always simply put a short comment like "Fixed in CVS, needs
documenting" and reclassify the bug report as docu issue. There's no
need for some fancy shortcuts or such. Just tune your process..
-
On Thursday 23 October 2008 08:54:19 Hannes Magnusson wrote:
> On Wed, Oct 22, 2008 at 20:59, Arnaud Le Blanc <[EMAIL PROTECTED]> wrote:
> > lbarnaudWed Oct 22 18:59:34 2008 UTC
> >
> > Modified files: (Branch: PHP_5_3)
> >/php-srcNEWS
> >/php-src/ext/socke
20 matches
Mail list logo
