On Sunday 20 November 2005 23:18, George Schlossnagle wrote:
> Doesn't work to well with
>
> $$moo{1};
Didn't think of that :)
> or
>
> $moo = array( 1 => 'foo');
> $moo{1};
I actaully didn't even know you could do that :)
So.. ignore my regex, but not my comment about decent docmentation for
Ian P. Christian wrote:
On Sunday 20 November 2005 22:27, Ian P. Christian wrote:
If this change included a simple sed command that could be applied to code
to fix 'legacy' code
Sorry, should have included this...
For example:
$ cat test
$ sed -e 's/$\([a-zA-Z][a-zA-Z0-9]*\){\(
On Sunday 20 November 2005 22:27, Ian P. Christian wrote:
> If this change included a simple sed command that could be applied to code
> to fix 'legacy' code
Sorry, should have included this...
For example:
$ cat test
$ sed -e 's/$\([a-zA-Z][a-zA-Z0-9]*\){\([0-9]*\)}/substr($\1,\2,1)/g' test
Hey guys,
Although I'm senile and I don't remember 100%, I believe Ralf is
right and the slight difference must have slipped in when I used his
optimized version of the hash function. I don't think I meant to make
the change from xor to addition.
I suggest to leave it as-is as, as there seems
On Sunday 20 November 2005 22:21, Christian Schneider wrote:
> I second that as people on the list here are undecided about the removal
> of {} for strings. Keeping that warning creates even more confusion
> about a really minor issue (having two ways of accesing strings offsets).
Whilst I'm not r
Sascha Schumann wrote:
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an E_STRICT warning on the usage of {} for accessing of string
offsets.
(Ilia)
I suggest removing that warning immediately until the matter
is resolved.
I second that as people on the list here are undecided abou
> This is a non-issue for phpDocumentor. All we need is at
> least 6 months
> to a year of lead time on the final decision in order to
> adjust the code.
As I wrote, I happend to have Smarty and phpDocumentor checkouts at
hand. I just checked a recently installed version of Mediawiki and they
Hello Bob,
in php 4 that prevents a useless copy after new (and dont't ask why).
Since your stuff is php 5 only you should make that is_ref=0.
marcus
Sunday, November 20, 2005, 6:55:49 PM, you wrote:
> Looking through the source, there are a few extensions which create objects
> internally an
Hello Stefan,
as said in private already. This pretty much looiooks like a take over
problem. And as a sidenote, loop unwinding with string algorithmns should
take care of byte alignment. Both said the code is damn wrong.
marcus
Sunday, November 20, 2005, 4:37:17 PM, you wrote:
> Hello,
> I
On Sun, 2005-11-20 at 09:37, Derick Rethans wrote:
> On Sun, 20 Nov 2005, Robert Cummings wrote:
>
> > On Sun, 2005-11-20 at 08:50, Derick Rethans wrote:
> > > On Sun, 20 Nov 2005, Matthias Pigulla wrote:
> > >
> > > > Changing language syntax that way back and forth again will cause a loss
> > >
Matthias Pigulla wrote:
As to the possible impact - I did a quick scan of Smarty and
phpDocumentor (because I used to have CVS HEAD checkouts of them at
hand) and found that both of them would be affected. Please, do not make
such a change that late in an RC5 and push it out with PHP5.1. At least
Rasmus Lerdorf wrote:
The PHP 6 stuff is still up in the air. The original suggestion was to
carry through with the deprecation of [] which I strongly vetoed since
it would break everything. We can revisit whether we want to remove {}
in PHP 6. I didn't think people had such strong feelings
Here the forwarded answer by Ralf Engelschall, because in the original
name the address of internals was wrong...
Stefan
--
--
Stefan Esser [EMAIL PROTECTED]
Hardened-PHP Proje
Looking through the source, there are a few extensions which create objects
internally and when they do this (usually with an instanciate method), they
typically set is_ref == 1. Like so:
object_init_ex(object, class_entry);
object->refcount = 1;
object->is_ref = 1;
Why set the is_ref?
Hello,
I just realised, that between PHP4 and PHP5 we changed the hash function
used within zend_hash.h from DJBX33X to DJBX33A. The diff is here =>
http://cvs.php.net/diff.php/ZendEngine2/zend_hash.h?ws=0&r1=1.57&r2=1.58&ty=u
Does anyone remember the exact reason for that? Or was the change done
Derick,
> If you prefer a PHP which causes strange crashses and memory
> corruptions, please downgrade to 4.3.11. I am getting tired
> about this
> bickering about this **FIX** that makes PHP stable.
You got me wrong here. I did not want to say anything against the 4.4.0
fix or even blame you f
On Sun, 20 Nov 2005, Robert Cummings wrote:
> On Sun, 2005-11-20 at 08:50, Derick Rethans wrote:
> > On Sun, 20 Nov 2005, Matthias Pigulla wrote:
> >
> > > Changing language syntax that way back and forth again will cause a loss
> > > in credibility - once again after the 4.4.0 release.
> >
> >
On Sun, 2005-11-20 at 08:50, Derick Rethans wrote:
> On Sun, 20 Nov 2005, Matthias Pigulla wrote:
>
> > Changing language syntax that way back and forth again will cause a loss
> > in credibility - once again after the 4.4.0 release.
>
> If you prefer a PHP which causes strange crashses and memor
On Sun, 20 Nov 2005, Matthias Pigulla wrote:
> Changing language syntax that way back and forth again will cause a loss
> in credibility - once again after the 4.4.0 release.
If you prefer a PHP which causes strange crashses and memory
corruptions, please downgrade to 4.3.11. I am getting tired
Roman Ivanov schrieb:
> Christian Schneider wrote:
>
>>Please think twice before breaking BC light-heartedly.
>
>
> Please brake BC completely, and rename everything, and reorder
> arguments, and replace array() with a(), and replace $this-> with
> something consise, and replace '->' with '.',
If I got that right, you still want to discourage {} and un-deprecate []
again, despite all the good reasons given on this list not to do so?
PHP5.1 would be accomplishing facts as to this one. ("Let's remove {}
altogether in 6 - nobody should be using them anyway as they were
deprecated since 5.1
The PHP_CompatInfo package simply evaluates a script to find which is the
minimum version of PHP able to run it. Obviously it'll need updating for
PHP 5.1, and it may well be a helpful tool for users deciding whether an
upgrade is a good idea, but it's unlikely to be useful in the context under
di
The issues were resolved in CVS.
Ilia
Marcus Bointon wrote:
> On 18 Nov 2005, at 11:58, Derick Rethans wrote:
>
>> Especially test
>> issues with mod_rewrite and Apache 2 please!
>
>
> Have these mod_rewrite problems also been addressed in 5.1? I'm getting
> exactly the symptoms described in
On 18 Nov 2005, at 11:58, Derick Rethans wrote:
Especially test
issues with mod_rewrite and Apache 2 please!
Have these mod_rewrite problems also been addressed in 5.1? I'm
getting exactly the symptoms described in bug 35059 in 5.1.0RC6,
though I didn't realise that's where the problem was
24 matches
Mail list logo
