On Thu, May 15, 2008 at 8:49 AM, Hector Santos <[EMAIL PROTECTED]> wrote:
> Folks,
>
> It has been suggested to me offlist that I should propose this idea on the
> list.
>
> I've seem recent discussions about the multi-os complexities of the make
> system for PHP, and there talk of using this new C
Folks,
It has been suggested to me offlist that I should propose this idea on
the list.
I've seem recent discussions about the multi-os complexities of the make
system for PHP, and there talk of using this new CMake system.
Rather than YALTM (yet another language to master, we should have a
Hi Stan,
I made a proposal and patch a few months ago at
http://news.php.net/php.internals/34097, which Julian later adapted to a
more recent version of PHP 5.3 at the time at
http://news.php.net/php.internals/36822 (don't know if the patch still
applies cleanly).
Unfortunately I haven't re
Making a first release of the PEAR package "PHP_UML", which has been accepted
by the PEAR community recently.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Gregory Beaver escribió:
Hi,
I wonder if there is any objection to this plan:
1) enable phar by default for the PHP 5.3 betas, so that it can receive
full testing
2) before RC1, do the formal vote on whether it should be enabled by
default in the release
Make sense, otherwise it wont be teste
Hi,
I'm looking at the current namespace resolution rules here:
http://www.php.net/manual/en/language.namespaces.rules.php
Something that bothers me is that for the first time in PHP we introduce a
hard difference in how internal functions and user functions are
resolved/called:
::foo(); // res
Go for it, we can always change our mind before the vote if something
comes up.
Scott
Gregory Beaver wrote:
Hi,
I wonder if there is any objection to this plan:
1) enable phar by default for the PHP 5.3 betas, so that it can receive
full testing
2) before RC1, do the formal vote on whether i
Hi,
I wonder if there is any objection to this plan:
1) enable phar by default for the PHP 5.3 betas, so that it can receive
full testing
2) before RC1, do the formal vote on whether it should be enabled by
default in the release
This way, phar can be tested for the possibility of enabling, but
Steph,
On Wed, 2008-05-14 at 13:59 +0100, "Steph Fox" wrote:
> I wrote a macro to allow us to use the same code for the extension in both
> branches, but it occurs to me that the zstr union definition might change or
> even disappear when PHP 6 becomes Unicode-only. Is that likely? I don't
> kn
On Wed, 2008-05-14 at 14:37 +0200, Christian Schneider wrote:
> Richard Quadling wrote:
> > _IF_ the property was defined in an interface, should "unset" be
> > "allowed" to remove the property?
>
> a) Interfaces do not define attributes, they define a set of methods.
> b) If the above would be c
2008/5/14 Gregory Beaver <[EMAIL PROTECTED]>:
> Richard Quadling wrote:
>> 2008/5/13 Antony Dovgal <[EMAIL PROTECTED]>:
>>
>>> On 13.05.2008 01:45, Gregory Beaver wrote:
>>>
Thanks to all who have contributed, particularly Marcus, Steph, Lars,
and the others who chimed in with ideas on th
Richard Quadling wrote:
> 2008/5/13 Antony Dovgal <[EMAIL PROTECTED]>:
>
>> On 13.05.2008 01:45, Gregory Beaver wrote:
>>
>>> Thanks to all who have contributed, particularly Marcus, Steph, Lars,
>>> and the others who chimed in with ideas on the list.
>>>
>> phar_detect_phar_fname_e
Hi all,
Is there any chance of getting the unicode.semantics issue sorted soon?
We put phar into php-src yesterday. I updated the extension in CVS HEAD just
to allow it to build, but it'd be good to have forward/sideward
compatibility from 5.3.0 in my view (and Greg's).
I wrote a macro to al
Richard Quadling wrote:
> _IF_ the property was defined in an interface, should "unset" be
> "allowed" to remove the property?
a) Interfaces do not define attributes, they define a set of methods.
b) If the above would be changed I still want to be able to shoot myself
in the foot if I *explicitel
2008/5/13 Antony Dovgal <[EMAIL PROTECTED]>:
> On 13.05.2008 01:45, Gregory Beaver wrote:
>>
>> Thanks to all who have contributed, particularly Marcus, Steph, Lars,
>> and the others who chimed in with ideas on the list.
>
> phar_detect_phar_fname_ext() fails if is_complete = 1 and filename contai
2008/5/14 Christian Schneider <[EMAIL PROTECTED]>:
>
> Am 14.05.2008 um 02:06 schrieb Marcus Boerger:
>>>
>>> So you are saying that
>>> $o_Foo->bar = array(42);
>>> is ok when the class "expects" a string but
>>> unset($o_Foo->bar);
>>> or (as as slight variation)
>>> $o->Foo->ba
Am 14.05.2008 um 02:06 schrieb Marcus Boerger:
So you are saying that
$o_Foo->bar = array(42);
is ok when the class "expects" a string but
unset($o_Foo->bar);
or (as as slight variation)
$o->Foo->bar = null;
is not?
I Do not get the connection here? And since when can we '
17 matches
Mail list logo
