> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 20, 2007 11:40 PM
> To: Andi Gutmans
> Cc: Andrei Zmievski; Lukas Kahwe Smith; Antony Dovgal; Rasmus Lerdorf;
> PHP Developers Mailing List
> Subject: RE: [PHP-DEV] What is the use of "unicode.seman
On Mon, 20 Aug 2007, Andi Gutmans wrote:
> On Tue, 21 Aug 2007, Derick Rethans wrote:
> >
> > On Mon, 20 Aug 2007, Andi Gutmans wrote:
> >
> > > No I'm absolutely not OK with removing this switch and as we currently
> > > did most of the implementation for it and are maintaining it I see no
> >
For PHP 5.1.1, I added an additional field $frame['object'] to the
result array of debug_backtrace() that contains a reference to the
respective object when the frame was called from an object.
What I did not think of at the time, unfortunately, is the fact that
unconditionally including $fra
On Mon, 20 Aug 2007, Stanislav Malyshev wrote:
> > And if Andrei, who is mostly behind (afaict) the whole thing, says he's okay
> > with getting rid of the totally useless option then in my eyes that's the
> > death sentence for the option.
>
> In your eyes - fine. But besides your personal eyes,
Well that's the problem. We have put months (if not more) of work into
PHP 6 but most people who are complaining aren't willing to take a stab
at actually help figuring this out.
No matter what we end up doing, the worst is if we make an arbitrary
decision because no one had time to get the right d
I don't think it's a matter of agreeing but rather we can try and figure out
how to get out of this stale mate. This includes going down the path I
suggested which includes doing some more homework to figure this out. I am
keeping an open mind and am willing to be convinced but I feel there's st
Andi Gutmans wrote:
Before we continue this discussion I think there are a couple of things
which would be useful data points:
a) What is the performance difference between an implicit Unicode app
and non-Unicode. If we have 3-4 apps ported over to Unicode_semantics=on
Honestly I do not see any
On Mon, 20 Aug 2007, Andi Gutmans wrote:
> No I'm absolutely not OK with removing this switch and as we currently
> did most of the implementation for it and are maintaining it I see no
> reason to remove it. 95% of our users couldn't care less about native
> Unicode support except for the perform
What happens if you mix them?
namespace baz;
namespace foo {
class Bar {
...
}
}
?>
That's not the fun yet. This is:
Now, is bar in namespace baz or not? I guess it is, otherwise it stops
making any sense. So now when you see in the code it says "class bar"
what do you do to kno
Before we continue this discussion I think there are a couple of things
which would be useful data points:
a) What is the performance difference between an implicit Unicode app
and non-Unicode. If we have 3-4 apps ported over to Unicode_semantics=on
with only true binary strings cast to binay and r
Gregory Beaver wrote:
> Rasmus Lerdorf wrote:
>> Right, which breaks the single-namespace per file rule. Opcode caches
>> work on a per-file basis, so I know for a single op_array that I will
>> never have to worry about a secondary namespace lookup because I know up
>> front which namespace I am
Greg: You say that the old java-package-style definition still works, in
addition to braces. I presume then that the following are equivalent:
What happens if you mix them?
Is the full name of the class then foo::Bar, baz::Bar, or foo::baz::Bar?
Would the compiler have a heart attack
Rasmus Lerdorf wrote:
> Right, which breaks the single-namespace per file rule. Opcode caches
> work on a per-file basis, so I know for a single op_array that I will
> never have to worry about a secondary namespace lookup because I know up
> front which namespace I am in. By allowing multiple na
Yep, we need to still review in detail but if it messes up the rules
Rasmus has pointed out then it's a real issue. I think this is actually
the reason why we didn't support it in our proposal.
Andi
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Monday, Augus
Gregory Beaver wrote:
> Rasmus Lerdorf wrote:
>> Sheez, guys, slow down a tad. Just because he says "no performance
>> penalty" in the description, doesn't make it true. Unless I missed
>> something in the patch, I don't see how I would resolve the symbols at
>> compile-time now which means it ha
Greg,
Will review your patch...
Thanks,
Andi
> -Original Message-
> From: Gregory Beaver [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 20, 2007 10:03 PM
> To: Rasmus Lerdorf
> Cc: internals Mailing List
> Subject: Re: [PHP-DEV] [PATCH] allowing multiple namespaces per file
> plus name
Rasmus Lerdorf wrote:
> Sheez, guys, slow down a tad. Just because he says "no performance
> penalty" in the description, doesn't make it true. Unless I missed
> something in the patch, I don't see how I would resolve the symbols at
> compile-time now which means it has been moved to the executor
Sheez, guys, slow down a tad. Just because he says "no performance
penalty" in the description, doesn't make it true. Unless I missed
something in the patch, I don't see how I would resolve the symbols at
compile-time now which means it has been moved to the executor and in
doing so it implies a
No I'm absolutely not OK with removing this switch and as we currently
did most of the implementation for it and are maintaining it I see no
reason to remove it. 95% of our users couldn't care less about native
Unicode support except for the performance hit they'd take due to the
slower functions a
On Mon, 20 Aug 2007, John Mendenhall wrote:
> I have recently upgraded from php 4.4.0, to php 4.4.7.
> I am running this on openbsd 3.6 i386.
I apologize for this error on my part, posting to this
list. I was told this was the list to post this kind of
question to, then was told I should not sen
I have recently upgraded from php 4.4.0, to php 4.4.7.
I am running this on openbsd 3.6 i386.
My configure options are as follows:
-
./configure \
--prefix=/usr/local/php4 \
--with-apxs=/usr/sbin/apxs \
--enable-debug \
--disable-cgi \
--enable-force-cgi-redirect \
--enable-discard-path
>> Hi,
>>
>> If bug is tagged as 'No feedback' (18556) or 'Won't fix' (35050) and can
>> be reproduced in current PHP5 and PHP6, is it closed or open? Or maybe
>> you
>> need other bug report?
>
> Wont fix means wont fix..and in this case 'no feedback' means also 'wont
> fix'
> since it's the same
On 8/20/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> In your eyes - fine. But besides your personal eyes, there is also such
> thing as consensus, and it wasn't achieved.
Excuse me but it is achieved, you only don't see it, or refuse to see it.
--Pierre
--
PHP Internals - PHP Runtime De
Tomas Kuliavas kirjoitti:
Hi,
If bug is tagged as 'No feedback' (18556) or 'Won't fix' (35050) and can
be reproduced in current PHP5 and PHP6, is it closed or open? Or maybe you
need other bug report?
Wont fix means wont fix..and in this case 'no feedback' means also 'wont fix'
since it's the
Hi,
If bug is tagged as 'No feedback' (18556) or 'Won't fix' (35050) and can
be reproduced in current PHP5 and PHP6, is it closed or open? Or maybe you
need other bug report?
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
For some reason only totally opposing people have Z in their email
address domain..
Even if it were true (which it isn't) - so what?
And if Andrei, who is mostly behind (afaict) the whole thing, says he's
okay with getting rid of the totally useless option then in my eyes
that's the death sen
Because we can't stay in the stasis forever? What concrete steps do
you propose to change the current situation?
-Andrei
http://10fathoms.org/vu - daily photoblog
On Aug 20, 2007, at 12:54 PM, Stanislav Malyshev wrote:
FINALLY we're getting somewhere. Now where to start removing all the
I
>>> FINALLY we're getting somewhere. Now where to start removing all the
>>
>> I don't see how we are getting somewhere - as before, there are people
>> for removing it and against removing it. Nothing changed, as far as I
>> see. Why suddenly should we start removing anything?
>
> For some reason
This is the wrong way to do things around here.
If you want something in, just commit and ignore the noise on this list.
--Jani
[EMAIL PROTECTED] kirjoitti:
Thanks. someone please commit that as fast as posible so no one can say anything
;-)
On 8/20/07, Gregory Beaver <[EMAIL PROTECTED]> wrot
On 20.08.2007 20:14, David Coallier wrote:
Time to put gas on the fire.
Is this flag going to be removed or what? What is happening here in
the background that we are not seeing ? :)
Nothing.
It's stuck.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
Thanks. someone please commit that as fast as posible so no one can say anything
;-)
On 8/20/07, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This patch is also available at
> http://pear.php.net/~greg/namespace.patch.txt
>
> The patch adds the syntax "namespace { *stuff }" and allows
Stanislav Malyshev kirjoitti:
FINALLY we're getting somewhere. Now where to start removing all the
I don't see how we are getting somewhere - as before, there are people
for removing it and against removing it. Nothing changed, as far as I
see. Why suddenly should we start removing anything?
Hi all,
This patch is also available at
http://pear.php.net/~greg/namespace.patch.txt
The patch adds the syntax "namespace { *stuff }" and allows multiple
namespaces per file with no performance penalty or added complexity as
only 4 lines of code need to be changed, and 9 lines of code added to
i
FINALLY we're getting somewhere. Now where to start removing all the
I don't see how we are getting somewhere - as before, there are people
for removing it and against removing it. Nothing changed, as far as I
see. Why suddenly should we start removing anything?
--
Stanislav Malyshev, Zend So
FINALLY we're getting somewhere. Now where to start removing all the crap that
was necessary for the non-unicode mode? (I'd say the tests..)
--Jani
Andrei Zmievski kirjoitti:
Nothing is happening, as far as I can tell. We are at an impasse,
basically. Personally, I am fine with removing the d
Nothing is happening, as far as I can tell. We are at an impasse,
basically. Personally, I am fine with removing the damn switch and
going forward with PHP 6 as Unicode-only. God knows it will rid us of
at least one headache - having to discuss it anymore.
-Andrei
http://10fathoms.org/vu -
On Mon, 2007-08-20 at 10:43 -0700, Tony Bibbs wrote:
> Having watched this thread intently for the past few weeks, we seem to
> be simply tripping over the semantics of it all, right?
>
> Thinking a bit outside the box, how hard would it be to simply use
> both names, one as an alias of the other?
Having watched this thread intently for the past few weeks, we seem to be
simply tripping over the semantics of it all, right?
Thinking a bit outside the box, how hard would it be to simply use both names,
one as an alias of the other? In the end the documentation will probably need
to outline
interesting, we are still in prototype formhmmm since when do we
commit proto types? I thought we are supposed to show patches until they
work as expected. So remembering the other new mails you guys wrote
recentlywe might drop all of this again, we might rename all of it, we
I don't t
On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> IMHO backporting a lot of features to PHP4 is a major reasons for the
> slow PHP5 adoption. Basically, it seems that everybody who is not using
> OOP feels that PHP4 is fine for them.
>
> I'd say committing to backporting stuff from PHP6 to PH
On 8/20/07, Robert Cummings <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-20 at 12:13 +0200, Marcus Boerger wrote:
> > Hello Dmitry,
> >
> > LOL, and in the future we have to rename PHP as it is no longer for
> > homepages?
>
> I thought it was renamed already to PHP Hypertext Processor :)
Yes,
On Mon, 2007-08-20 at 12:13 +0200, Marcus Boerger wrote:
> Hello Dmitry,
>
> LOL, and in the future we have to rename PHP as it is no longer for
> homepages?
I thought it was renamed already to PHP Hypertext Processor :)
Cheers,
Rob.
--
..
I had always assumed this was down to the use of __set
class foo
{
function __set($var, $value) { }
}
$o = new foo;
$o->b = $o->b + 5;
$o->c += 5;
Displays the exact same properties.
Scott
Jakub Vrana wrote:
> PHP have the Undefined variable/property notice to inform a programmer
> abo
On Mon, 20 Aug 2007, Jakub Vrana wrote:
> PHP have the Undefined variable/property notice to inform a programmer
> about using uninitialized variables/properties. While both $b = $b + 5
> and $c += 5 issues the notice (and also $a["b"] = $a["b"] + 5 and
> $a["c"] += 5 in case of arrays), in case o
PHP have the Undefined variable/property notice to inform a programmer
about using uninitialized variables/properties. While both $b = $b + 5
and $c += 5 issues the notice (and also $a["b"] = $a["b"] + 5 and
$a["c"] += 5 in case of arrays), in case of objects only $o->b = $o->b + 5
issues the notic
Hello Stanislav,
interesting, we are still in prototype formhmmm since when do we
commit proto types? I thought we are supposed to show patches until they
work as expected. So remembering the other new mails you guys wrote
recentlywe might drop all of this again, we might rename all of i
Hello Dmitry,
LOL, and in the future we have to rename PHP as it is no longer for
homepages?
Friday, August 17, 2007, 9:01:12 AM, you wrote:
> Hi,
> We are still working on namespace concept and its features.
> I am not sure that existing concept will work well as is.
> So please, don't mak
Hello Gregory,
the good news on this fron is that re2c meanwhile has a new beta version
with flex like conditoin support. Also when changing from flex to re2c we
should switch from bison to lemon. All in all a damn huge amount of work.
But the result would be much cleaner, faster, more flexible,
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (55 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
27372 Assigned parse error loadin
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (629 total including feature requests)
===[*General Issues]==
42165 Open fsockopen ssl Operation now in progress (115)
===
50 matches
Mail list logo
