We are working on this feature and additional patch will be posted for
review on this week.
Thanks. Dmitry.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
> Sent: Friday, August 17, 2007 8:24 PM
> To: PHP Internals List
> Subject: [
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 patc
pecl/intl project
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 misspell
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
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 s
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 cou
Stanislav Malyshev wrote:
>> file1.php:
>> > namespace foo;
>> class bar {}
>> ?>
>>
>> file2.php:
>> > namespace gronk;
>> import foo::bar;
>> class bar {}
>> ?>
>
> The problem is not this code. The problem is this code:
>
> file1.php
> namespace foo;
> import otherfoo::bar;
> ?>
>
> file2.php:
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 hea
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
m
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:
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 fil
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 th
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 Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
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 th
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 esse
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?
That's not the fun yet. This is:
If by fun you mean "Fatal er
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 a
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 PH
Stanislav Malyshev wrote:
>> What happens if you mix them?
>> >
>> namespace foo {
>> class Bar {
>> ...
>> }
>> }
>> ?>
>
> That's not the fun yet. This is:
>
> namespace baz;
>
> namespace foo { ...whatever... }
>
> class bar {}
>
> ?>
If by fun you mean "Fatal error: Namespace ca
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 {
> includ
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:
>
> namespace foo;
>
> class Bar {
> ...
> }
> ?>
>
> namespace foo {
> class Bar {
> ...
> }
> }
> ?>
>
> What
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 k
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 \
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 had
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
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
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-
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 w
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
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 o
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 unicode.se
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
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
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 application,
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 add
> -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.sema
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
PHP
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 PROT
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
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 PH
> 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
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
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
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 e
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 t
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 ra
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 things
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 of
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: G
50 matches
Mail list logo
