Lukas Kahwe Smith wrote:
On 22.11.2008, at 14:52, Lukas Kahwe Smith wrote:
Work is still going on to finalize the namespace changes. I am not
sure when this will be done, I am sort of hoping Monday. Then we can
freeze Tuesday and release on Thursday if all goes well.
The good news,
On Wed, Nov 26, 2008 at 12:20 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 22.11.2008, at 14:52, Lukas Kahwe Smith wrote:
Work is still going on to finalize the namespace changes. I am not sure
when this will be done, I am sort of hoping Monday. Then we can freeze
Tuesday and release on
On Wed, 2008-11-26 at 19:36 +0300, Alexey Zakhlestin wrote:
Following files are still not converted to the new parameter parsing API:
- ext/mysql/php_mysql.c
That's mostly done, some small issues left, will commit before alpha ...
- ext/mysqli/mysqli_embedded.c
That's not done yet, but only
Em Qua, 2008-11-26 às 19:36 +0300, Alexey Zakhlestin escreveu:
On Wed, Nov 26, 2008 at 12:20 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 22.11.2008, at 14:52, Lukas Kahwe Smith wrote:
Work is still going on to finalize the namespace changes. I am not sure
when this will be done, I
On 26.11.2008, at 11:21, Scott MacVicar wrote:
Independent of that I need someone to handle the move of ext/mhash
to PECL.
Why not just delete the extension? There isn't anything valuable in
there as it just wraps around hash now, it is literally an empty
module
and a configure
Hi!
Then again, we maintain BC aside from this single call to determine if
the extension is loaded, so I guess yeah .. lets just remove it .. we
are expecting people to update their code.
If we have function-level BC - why not just add stub extension with
dependency on hash?
--
Stanislav
Hello Stanislav,
why not have a secondary extension definition in ext/hash?
Wednesday, November 26, 2008, 7:06:03 PM, you wrote:
Hi!
Then again, we maintain BC aside from this single call to determine if
the extension is loaded, so I guess yeah .. lets just remove it .. we
are
Hi!
why not have a secondary extension definition in ext/hash?
Would be fine too, if loading can handle that correctly.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development
On 26 Nov 2008, at 18:56, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Stanislav,
why not have a secondary extension definition in ext/hash?
Wednesday, November 26, 2008, 7:06:03 PM, you wrote:
Hi!
Then again, we maintain BC aside from this single call to
determine if
the extension is
Lukas Kahwe Smith wrote:
Hello all,
Just some observations. Keep in mind I am just trying to see in what
area's we should try and find people to help out. So please do not
interpret this email as me telling people what they should do with their
time. However I am, just like Jani, a bit
On Wed, Nov 26, 2008 at 20:21, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
why not have a secondary extension definition in ext/hash?
Would be fine too, if loading can handle that correctly.
Don't we do that already?
What exactly was the vote from last week about? I thought it was about
Hello Scott,
Wednesday, November 26, 2008, 8:33:59 PM, you wrote:
On 26 Nov 2008, at 18:56, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Stanislav,
why not have a secondary extension definition in ext/hash?
Wednesday, November 26, 2008, 7:06:03 PM, you wrote:
Hi!
Then again, we
Hi!
On Wed, Nov 26, 2008 at 8:45 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
That's one solution, the other is to reqister that stub extension from
MINIT of the hash extension and be done (can all be done in hash.c).
It was what we decided weeks ago already. I'mm not sure why it is not done
On Nov 24, 2008, at 9:27 PM, Christopher Vogt wrote:
Interfaces are helpful in combination with type hinting, but for
people who prefer
duck typing, it is reasonable to not explicitly define them.
It sounds like you are saying that if you prefer duck typing then
interfaces have no use.
14 matches
Mail list logo
