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
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
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
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
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, there
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
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
reason to
-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.semantics in
How about import statements?
The had effect on current file. How they will behave with your patch?
The import in one namespace will affect following namespaces... :)
Also this change is inconsistent with renaming namespace to package.
Thanks. Dmitry.
-Original Message-
From: Gregory
Andi Gutmans wrote:
Anyway, as I suggested, let's do more homework. We started and it wasn't a
pretty sight. But still lots to do. There seem to be enough passionate people
on this list to actually port 3-4 apps over and give us some more input on the
answers we really need.
I have kept out
Andi Gutmans wrote:
Maybe you guys can try with ezComponents?
So whats your target with this BC flag .. make it possible to have
PHP4-PHP6 (unicode off) apps?
Keep in mind that the camp that is suggesting to remove the unicode flag
is at the same time committing to back porting more
So what happened to the Open in OpenSource or is PHP now something
else now?
btw. 95% of Zend users propably don't need unicode but there are a lot
more people out there who can't really use PHP right now since it
doesn't have full unicode support. The percents pulled out of sleeve
would be
On Mon, 2007-08-20 at 17:56 -0700, John Mendenhall wrote:
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
On Tue, 2007-08-21 at 08:18 +0200, Derick Rethans wrote:
On Mon, 20 Aug 2007, Andi Gutmans wrote:
Anyway, don't want to reignite the thread here. I will take it offline
to discuss with the people who have been involved in this project and
discuss further. The mailing list here isn't exactly
On 21/08/07, Jani Taskinen [EMAIL PROTECTED] wrote:
On Tue, 2007-08-21 at 08:18 +0200, Derick Rethans wrote:
On Mon, 20 Aug 2007, Andi Gutmans wrote:
Anyway, don't want to reignite the thread here. I will take it offline
to discuss with the people who have been involved in this project
Hello Dmitry,
LOL!
climbing up the chair again, this is the most stupiest arguemnt ever.
didn't you just yesterday suggest we keep it namespace anyway until we
are done. And didn't you guys say that we might end up with something that
really is namespaces anyway.
Please guyse read your own
So what happened to the Open in OpenSource or is PHP now something
else now?
btw. 95% of Zend users propably don't need unicode but there are a lot
more people out there who can't really use PHP right now since it
doesn't have full unicode support. The percents pulled out of sleeve
would be
On Tue, 2007-08-21 at 08:31 +0100, Lester Caine wrote:
How much work do people think *IS* involved in porting a large application
over to PHP6? Reading between the lines it looks like we are talking file
conversion to UTF-16 + what? What is currently a show stopper to simply
running a PHP5
Marcus,
You can laugh as you like.
I never said that I didn't like rename namespace to package.
I asked to wait with decision because the whole concept is not finalized
yet.
For example packages and multiple namespaces in single file are
inconsistent.
Anyway, I prefer developing PHP than argue
Uhm, what makes you think we don't have asian users? I also don't recall
suggesting that we should not have Unicode support.
Don't forget how much we invested in implementing this in the engine. It
was far from trivial...
Andi
-Original Message-
From: Jani Taskinen [mailto:[EMAIL
Hi,
Ok, so I think its becoming clear that BC is not the main issue we will
be addressing with the unicode switch. I know Zeev's mantra that BC is
not binary, but from the people that have posted feedback on the topic
from actual experience it seems that making code work on PHP5 (and even
-Original Message-
From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 21, 2007 1:30 AM
To: Andi Gutmans
Cc: Derick Rethans; Andrei Zmievski; Antony Dovgal; Rasmus Lerdorf; PHP
Developers Mailing List
Subject: Re: [PHP-DEV] What is the use of unicode.semantics
The current php.ini-recommended in CVS for 5.2 has this at line 95...
; - magic_quotes_gpc = Off [Performance]
; Input data is no longer escaped with slashes so that it can be
sent into
; SQL databases without further manipulation. Instead, you should
use the
; function
Hi everybody,
I first want to personally thank everybody who have voiced their opinions on
this subject as it shows how much concern you all have for PHP.
To give a bit of background, I am one of the PHP Google Summer of Code
students and part of my project was to port/create a PHP 6
On Tue, Aug 21, 2007 at 04:26:21PM +0100, Stut wrote:
As far as I was aware addslashes is inadequate for this purpose. Should
this not point people to use database-specific escaping functions rather
than addslashes?
Yes, even better use placeholders (if the DB API supports it).
--
Alain
Managing PECL/INTL project for Yahoo. Stas can vouch for me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nicolas Bérard-Nault wrote:
I have one specific example of where this can be a HUGE headache. Let's
say you have some serialized configuration files, saved with
unicode.semantics = 1, containing a single configuration array. Now, for
some reason, the administrator decides to turn
On Tue, 21 Aug 2007, Jani Taskinen wrote:
On Mon, 2007-08-20 at 17:56 -0700, John Mendenhall wrote:
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,
There is now another 3 extensions added and the broken ones have yet to
see any sort of love to get them working.
I'm for removing the non stable PECL extensions or at least those that
don't even load, especially before 5.2.4.
Scott
John Mertic wrote:
Hi,
On 7/2/07, Antony Dovgal [EMAIL
Hello Dmitry,
LOL!
climbing up the chair again, this is the most stupiest argument ever.
Could you please keep the attitude down? Calling names is not going to
help anything.
didn't you just yesterday suggest we keep it namespace anyway until we
are done. And didn't you guys say that
Make a list of what's considered non-stable and I can drop them from
the builds for 5.2.4.
On 8/21/07, Scott MacVicar [EMAIL PROTECTED] wrote:
There is now another 3 extensions added and the broken ones have yet to
see any sort of love to get them working.
I'm for removing the non stable PECL
Involved in the development of pecl/intl project. Request Referred by -
Stanislav Malyshev and Tex Texin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 2007-08-20 at 17:52 -0700, 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.
My configure options are as follows:
-
./configure \
--prefix=/usr/local/php4 \
--with-apxs=/usr/sbin/apxs \
--enable-debug \
These simply dont work:
Thread - crashes on shutdown
iisfunc - crashes on shutdown
SAM - tries to load a file via include during RINIT
I enabled all extensions minus those three and my installation still
works, those would be the priority.
The following are only avilable in CVS and have never
Johannes,
On Tue, 21 Aug 2007, Johannes Schlüter wrote:
On Mon, 2007-08-20 at 17:52 -0700, 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.
My configure options are as follows:
-
./configure \
Added a hack to care of that for 5.2.4.
I see a few possibilities for a future solution to the problem:
1) Include builds from HEAD for only a certain set of known stable
PECL extensions ( APC, uploadprogress, etc ).
2) Include builds from HEAD for all PECL extensions that build, but
put those
Larry Garfield wrote:
Greg: You say that the old java-package-style definition still works, in
addition to braces. I presume then that the following are equivalent:
?php
namespace foo;
class Bar {
...
}
?
?php
namespace foo {
class Bar {
...
}
}
?
What happens
Hi,
I'll try to answer some of the questions I saw here based on Gregory's
patch and I will ask for more information about external things that I
probably misunderstood.
And nested namespaces really make a mess of this if something like this
is allowed:
foo.inc:
namespace A {
include
Stanislav Malyshev wrote:
What happens if you mix them?
?php namespace baz;
namespace foo {
class Bar {
...
}
}
?
That's not the fun yet. This is:
?php
namespace baz;
namespace foo { ...whatever... }
class bar {}
?
If by fun you mean Fatal error: Namespace cannot
If there's an overwhelming support for removing the switch then I guess
that's where it is. I still think it's a mistake and we are risking a
big split in the user base going forward but time will tell. Long term
PHP may not recover from that split unless we truly manage to help the
most popular
Dmitry Stogov wrote:
How about import statements?
The had effect on current file. How they will behave with your patch?
The import in one namespace will affect following namespaces... :)
That's correct, import remains a per-file operation, and I pray to god
that no one suggests making it
I think there should be just one way to designate a namespace, not
two different ones with different behaviors.
David
Am 21.08.2007 um 21:09 schrieb Gregory Beaver:
Stanislav Malyshev wrote:
What happens if you mix them?
?php namespace baz;
namespace foo {
class Bar {
...
}
}
?
Rasmus Lerdorf wrote:
Well, outside of an opcode cache, you wouldn't care whether the logic is
in the compiler or the executor. But once you introduce an opcode
cache, anything that you can resolve at compile-time means one less
thing to do at execute time which means that the feature
David Zülke wrote:
I think there should be just one way to designate a namespace, not two
different ones with different behaviors.
Hi David,
First, the behaviors are not different, just the syntax. Of course you
can have more than one namespace per file with brackets, but the stuff
within
?php
namespace baz;
namespace foo { ...whatever... }
class bar {}
?
If by fun you mean Fatal error: Namespace cannot be declared twice
(without brackets) or nested within brackets in ...
Ah, I didn't read it good enough - was under impression mixing them was
allowed.
--
Stanislav
Greg,
sorry, behavior was probably not the right word. In any case, they
are different, because the one approach allows users to declare just
one namespace, and the other one allows to declare any number of
namespaces. That's what I meant. There really is no need for
ambiguities like
that if you try to combine two files that contain import statements,
it will be necessary to expand the imports. Fortunately, since
What do you mean by expand?
import allows aliasing specific namespaced files and classes within a
file. For example:
But import has nothing to do with files.
Stanislav Malyshev wrote:
that if you try to combine two files that contain import statements,
it will be necessary to expand the imports. Fortunately, since
What do you mean by expand?
import allows aliasing specific namespaced files and classes within a
file. For example:
But import
Careful Stas :), you probably missed the import foo::bar; This code
works just fine:
No I didn't. That's the whole point - once you do import outside
namespace, you can break stuff inside. Namespace is supposed to be
isolated from other namespaces, that's the whole point of it. But if you
portable as possible. To create a portable application for PHP 6, you have
to consider the two different unicode.semantics scenarios AND the
possibility that the switch, for some reason, might be turned on or off at
any time in the future. Even if you don't care about Unicode and/or have
never
Stanislav Malyshev wrote:
file1.php:
?php
namespace foo;
class bar {}
?
file2.php:
?php
namespace gronk;
import foo::bar;
class bar {}
?
The problem is not this code. The problem is this code:
file1.php
?php
namespace foo;
import otherfoo::bar;
?
file2.php:
?php
namespace
Right, that's why I was saying expansion of imports would be necessary,
meaning that all references to bar would need to be translated to
otherfoo::bar
Thatnslated by whom? How? I'm not sure I understand.
CG(current_import) = CG(saved_import) and freeing CG(saved_import).
This would of course
On Tuesday 21 August 2007, Guilherme Blanco wrote:
Also, mentioning the Rasmus piece of code:
foo.inc:
namespace A {
include 'bar.inc';
}
bar.inc:
namespace B {
...
}
I don't know how do you control it internally, but as long as this is
the only call in the entire script, the
Andi,
Is there a guide somewhere for those who are PHP developers, not C developers,
who would want to try existing code under PHP 6 but don't know all the ins
and outs of the new unicode system? It sounds like there's 3-4 unicode
switches in php.ini, but maybe I'm missing some and I'm sure I
Hi again,
The attached patch:
1) adds unset import syntax for declaring a namespace to have local
import scope (it does NOT affect variable scope or the global
class/function table)
2) removes namespace Name; syntax (this I am happy to add this back in
if there is uproar)
3) fixes all
pecl/intl project
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Guilherme Blanco wrote:
I don't understand very well what Rasmus tried to mention with nested
namespaces and opcache, but seems there're a limitation and I am
interested to know which (if possible, try to explain in other
words)... =)
Why am I asking this? I am changing the Gregory's patch...
57 matches
Mail list logo
