Re: [PHP-DEV] Inconsistencies in 5.3
Hello everybody,
Am Dienstag, den 12.08.2008, 03:04 +0200 schrieb Etienne Kneuss:
[...]
> To me
>
> namespace A {
>code
> }
>
> namespace B {
>code
> }
>
> code
>
> seems equivalent to
>
> namespace A;
> code
> namespace B;
> code
> namespace ;
> code
>
> Only nicer. And I can hardly how it's going to cause more problems?
> But if that's so, fine.
[...]
Just one thing: we developed around 50.000 lines of code with the
current namespace syntax and it was neither confusing nor inconsistent
to use. I'm very happy with the current syntax and I would like to just
leave it as it is.
Also I'm really against the curly braces: the issue is, that we would
indent the single class in the file then as otherwise the sense of
braces would be caricatured: we indent to make sure we can easily
distinguish control structures. But if we indent the content of a
namespace, we will have less characters until the magic 80-100 character
border and therefore we will have linebreaks in conditions which makes
them hard to read.
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Inconsistencies in 5.3
Hello,
On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>> but if the {} syntax is introduced, it will be made to affect only the
>> code inside it, right? If so, I fail to see your point, since the new
>> syntax will solve that problem.
>
> While introducing a whole collection of new problems - such as that we will
> have now split scope, that you can get in and out many times in the same
> file. As we discussed on the list many times, it's not exactly what we want
> and definitely not the use case it was designed for. I don't see any use for
> it besides promoting bad coding practices.
To me
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
namespace A;
code
namespace B;
code
namespace ;
code
Only nicer. And I can hardly how it's going to cause more problems?
But if that's so, fine.
My point is that if we are going to allow multiple namespaces per file
solely on the perspective of permitting packaging, we should also
allow mixing namespaced and non-namespaced code for that same
perspective, and the current syntax is not going to allow that.
I'd really like the {} syntax if multiple namespaces per file is
allowed. If it's not, then it's not much more than syntactic sugar and
I couldn't care less.
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED] http://www.zend.com/
> (408)253-8829 MSN: [EMAIL PROTECTED]
>
>
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! 3. You want another namespace, just write namespace again. No, that's not for kids to play with. That's grown-up stuff. Rated X. 4. You got lost after the 10th namespace? Welcome to if-else nesting Get your hands away from the keyboard and re-read the part about "not using multiple namespaces per file" :) If not convincing - stop using namespaces until it is :) Some coding style guides force curly braces for if-else for a reason. If you know what "coding style" means you are not using multiple namespaces per file anyway. If you don't - well, then all bets are off :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! "triskaidekaphobia" - oh and there was that very polemic pythin argument. Dude I am sorry but ther is no argument at all. Unless your long mail is Please ask you sysadmin to fix your mail system, you seem to be losing emails. The email I was referring to please read here: http://news.php.net/php.internals/39838 After that, we can continue discussion to the point, if you wish so. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
but if the {} syntax is introduced, it will be made to affect only the
code inside it, right? If so, I fail to see your point, since the new
syntax will solve that problem.
While introducing a whole collection of new problems - such as that we
will have now split scope, that you can get in and out many times in the
same file. As we discussed on the list many times, it's not exactly what
we want and definitely not the use case it was designed for. I don't see
any use for it besides promoting bad coding practices.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav,
Tuesday, August 12, 2008, 1:34:49 AM, you wrote:
> Hi!
>> "I don't want braces because people would think it acts like C++" is as
>> silly as saying "I don't want the current namespace Foo; syntax because
>> people will think it acts like python"
> Errr... as far as I know Python has no "namespace Foo;" syntax. And as I
> repeated numerous times, the syntax should be driven primarily by
> function, not by what decision some guys (even very smart guys) took
> when they designed entirely different language. The function of PHP
> namespaces makes {} make little sense, since {} implies bounded (and
> potentially nested) scope, that is repeatable and has "inside" and
> "outside".
>> Thinking as a new user...
>> How is
>> namespace foo;
>> semantically different from
>> class foo {}
>> or even
>> function foo {}
> 1. Namespace is a tag on the entities defined inside this file, function
> is not. Class can be viewed as such, kind of, but it'd be very limiting
> view (class is more than just tag on set of function names).
> 2. Class and function exist as stand-alone entity, namespace does not.
> 3. There can be context outside class/function in this file, but not
> outside namespace.
>> I'm defining something yes? With stuff basically "inside it". Yes an
>> oversimplification, but the strength of PHP has always been simple. So
>> why should it act differently? Why does it need different syntax to
>> define something?
> Well, it should act differently for the same reason class and function
> act differently - because they are different things. ITYM "why the
> should _look_ differently?". As I said, that is because for them to look
> the same would be to imply things about namespaces that are not true.
>> But at the end of the day this is all personal preference. Just
>> remember the poor people who have to teach this to the new users ;)
> I can help with that. Here's world's shortest course on PHP namespaces:
> 1. To define namespace for the file, write "namespace Foo::Bar;" at the
> beginning of the file.
> 2. That's it, enjoy. ;)
3. You want another namespace, just write namespace again.
4. You got lost after the 10th namespace? Welcome to if-else nesting
ambiguty all over again.
Some coding style guides force curly braces for if-else for a reason.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav, Tuesday, August 12, 2008, 1:41:08 AM, you wrote: > Hi! >> Sorry but you never ever provided any logical reasoning for the current >> way. The reasons that were brought up were: > It would help the discussion a lot if you actually read my emails. > Unfortunately, by now it's clear that you do not. I just wrote a long > email outlining the reasons, but I guess reading it would be too much work. >> a) JavaScript will have it in some future >> b) We used to have in our first implementation >> c) We said we were adding namespaces at some point, not saying in which way >>we would. I just read this from you: "We could use "package" or we could use "hexaflexagon" or we could use "triskaidekaphobia" - oh and there was that very polemic pythin argument. Dude I am sorry but ther is no argument at all. Unless your long mail is still on the way. You vary between polemic and spin around arguments reusing them at will. You promise we discuss and never agree too. Sorry but for the namespace discussion that is all that made it to me. And I am sure when I write something hardly anything makes it to you :-) We can just agree to disagree, so it is for others to decide about. That's what Lukas' mail was all about, collecting arguments, actually finding someone to collect and weigh them. And that's why I brought up those three points, because those are the arguments I do remember - apart from tons of mails that had no content at all or somehow got filtered by my incoming mail reading process :-) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello,
On Tue, Aug 12, 2008 at 2:12 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>> I fail to see why { } meaning a different level of hierarchy is a
>> problem here, that's exactly what it's supposed to mean: "code in that
>> block is affected by that namespace."
>
> Exactly. The thing is that there can be no code that is not affected (at
> least not in this file) for namespaces - and {} implies there could be.
but if the {} syntax is introduced, it will be made to affect only the
code inside it, right? If so, I fail to see your point, since the new
syntax will solve that problem.
>
>> We don't expect if's to work until the next if(), do we? Even though
>> ifs are not "entities like classes or functions".
>
> Exactly. That's why it makes sense to have if() with braces - because if
> works not until the end of file, but only with the block attached to it, and
> after this block ends, it's like there was no if. But namespace doesn't work
> this way.
Same as before: but they would work this way with the {} syntax
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED] http://www.zend.com/
> (408)253-8829 MSN: [EMAIL PROTECTED]
>
>
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
I fail to see why { } meaning a different level of hierarchy is a
problem here, that's exactly what it's supposed to mean: "code in that
block is affected by that namespace."
Exactly. The thing is that there can be no code that is not affected (at
least not in this file) for namespaces - and {} implies there could be.
We don't expect if's to work until the next if(), do we? Even though
ifs are not "entities like classes or functions".
Exactly. That's why it makes sense to have if() with braces - because if
works not until the end of file, but only with the block attached to it,
and after this block ends, it's like there was no if. But namespace
doesn't work this way.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello,
On Tue, Aug 12, 2008 at 12:58 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>> So why the $%#$%& can't we use "package" if the implementation has
>> nothing incommon with namespaces in c++ (your example, not mine)?
>
> We could use "package" or we could use "hexaflexagon" or we could use
> "triskaidekaphobia" or any other word. But if we have namespace
> implementation in PHP, why don't we call it "namespace"? Because it is
> "inconsistent" with C++? To hell with C++ then, nobody said PHP is C++.
>
>> Well. I do want that indentation if I ever will be dumb enough to have
>> multiple namespace in the same file..
>
> Indentation happens when you do () even once. {} implies that everything
> inside it is on next level of hierarchy and thus should be indented.
> Of course, it's "inconsistent" with Python, so maybe we should drop braces
> altogether...
I fail to see why { } meaning a different level of hierarchy is a
problem here, that's exactly what it's supposed to mean: "code in that
block is affected by that namespace."
We don't expect if's to work until the next if(), do we? Even though
ifs are not "entities like classes or functions".
Additionally, I see the packaging argument being raised to advocate
the use of multiple namespaces per file. However, with that syntax,
you can't package namespaced and non namespaced code in the same file
anyway, that sounds to me like a burden and actually a point against
the current syntax.
>
>> Its not about consistency for me. Its about that little gut feeling you
>> have.
>
> Well, of course I can not address little gut feeling with any logical
> argument. But to hell with logic and reasoning, let the little gut feeling
> rule.
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED] http://www.zend.com/
> (408)253-8829 MSN: [EMAIL PROTECTED]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
Regards,
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! Sorry but you never ever provided any logical reasoning for the current way. The reasons that were brought up were: It would help the discussion a lot if you actually read my emails. Unfortunately, by now it's clear that you do not. I just wrote a long email outlining the reasons, but I guess reading it would be too much work. a) JavaScript will have it in some future b) We used to have in our first implementation c) We said we were adding namespaces at some point, not saying in which way we would. Sadly, this has nothing to do with my reasoning. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
"I don't want braces because people would think it acts like C++" is as
silly as saying "I don't want the current namespace Foo; syntax because
people will think it acts like python"
Errr... as far as I know Python has no "namespace Foo;" syntax. And as I
repeated numerous times, the syntax should be driven primarily by
function, not by what decision some guys (even very smart guys) took
when they designed entirely different language. The function of PHP
namespaces makes {} make little sense, since {} implies bounded (and
potentially nested) scope, that is repeatable and has "inside" and
"outside".
Thinking as a new user...
How is
namespace foo;
semantically different from
class foo {}
or even
function foo {}
1. Namespace is a tag on the entities defined inside this file, function
is not. Class can be viewed as such, kind of, but it'd be very limiting
view (class is more than just tag on set of function names).
2. Class and function exist as stand-alone entity, namespace does not.
3. There can be context outside class/function in this file, but not
outside namespace.
I'm defining something yes? With stuff basically "inside it". Yes an
oversimplification, but the strength of PHP has always been simple. So
why should it act differently? Why does it need different syntax to
define something?
Well, it should act differently for the same reason class and function
act differently - because they are different things. ITYM "why the
should _look_ differently?". As I said, that is because for them to look
the same would be to imply things about namespaces that are not true.
But at the end of the day this is all personal preference. Just
remember the poor people who have to teach this to the new users ;)
I can help with that. Here's world's shortest course on PHP namespaces:
1. To define namespace for the file, write "namespace Foo::Bar;" at the
beginning of the file.
2. That's it, enjoy. ;)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav,
Tuesday, August 12, 2008, 12:58:29 AM, you wrote:
> Hi!
>> So why the $%#$%& can't we use "package" if the implementation has
>> nothing incommon with namespaces in c++ (your example, not mine)?
> We could use "package" or we could use "hexaflexagon" or we could use
> "triskaidekaphobia" or any other word. But if we have namespace
> implementation in PHP, why don't we call it "namespace"? Because it is
> "inconsistent" with C++? To hell with C++ then, nobody said PHP is C++.
>> Well. I do want that indentation if I ever will be dumb enough to have
>> multiple namespace in the same file..
> Indentation happens when you do () even once. {} implies that everything
> inside it is on next level of hierarchy and thus should be indented.
> Of course, it's "inconsistent" with Python, so maybe we should drop
> braces altogether...
>> Its not about consistency for me. Its about that little gut feeling you have.
> Well, of course I can not address little gut feeling with any logical
> argument. But to hell with logic and reasoning, let the little gut
> feeling rule.
Sorry but you never ever provided any logical reasoning for the current
way. The reasons that were brought up were:
a) JavaScript will have it in some future
-> works in the same way as C++ has this or Java that
b) We used to have in our first implementation
-> which by the way used curly braces, and the only reason we we dropped it
was because I was outruled by you and Zeev when we encountered the
ternariy ambiguty and noone tought it was fixable even though I said it
was fixable. Sadly I never provided a working patch back then.
c) We said we were adding namespaces at some point, not saying in which way
we would.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hello Christian, Tuesday, August 12, 2008, 12:34:41 AM, you wrote: > Hi Marcus, >> Account approved and access granted. > Thanks! >> Please provide the function copying in a function next to _free_function() > I just committed that (and included some tests). I hope I didn't do > anything wrong in the process, if so, feel free to do so. >> and care for parameter info as well > I assume with parameter info you mean arg_info? That isn't necessary and > actually harmful since the arg_info is not copied but simply referenced > via a C pointer in closures (zend_get_closure_invoke_method copies the > entire function structure, including the pointer to arg_info and only > changes some flags the function name). There is no need to copy or > destroy arg_info in reflection. Oh, cool. I thought we'd have to do more stuff. >> Also for your next patches (cvs di -N) allows to ship the new files in the >> patch and (cvs di -Np) shows the context, which makes reading the patches >> easier. > Ah, thanks, I added that to my .cvsrc. > Regards, > Christan Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
So why the $%#$%& can't we use "package" if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
We could use "package" or we could use "hexaflexagon" or we could use
"triskaidekaphobia" or any other word. But if we have namespace
implementation in PHP, why don't we call it "namespace"? Because it is
"inconsistent" with C++? To hell with C++ then, nobody said PHP is C++.
Well. I do want that indentation if I ever will be dumb enough to have
multiple namespace in the same file..
Indentation happens when you do () even once. {} implies that everything
inside it is on next level of hierarchy and thus should be indented.
Of course, it's "inconsistent" with Python, so maybe we should drop
braces altogether...
Its not about consistency for me. Its about that little gut feeling you have.
Well, of course I can not address little gut feeling with any logical
argument. But to hell with logic and reasoning, let the little gut
feeling rule.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hi Marcus, Account approved and access granted. Thanks! Please provide the function copying in a function next to _free_function() I just committed that (and included some tests). I hope I didn't do anything wrong in the process, if so, feel free to do so. and care for parameter info as well I assume with parameter info you mean arg_info? That isn't necessary and actually harmful since the arg_info is not copied but simply referenced via a C pointer in closures (zend_get_closure_invoke_method copies the entire function structure, including the pointer to arg_info and only changes some flags the function name). There is no need to copy or destroy arg_info in reflection. Also for your next patches (cvs di -N) allows to ship the new files in the patch and (cvs di -Np) shows the context, which makes reading the patches easier. Ah, thanks, I added that to my .cvsrc. Regards, Christan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request: cseiler
Welcome aboard (soon), and congrats for your patchs. -- Cordialement. -- Nicolas Chaillan | GROUPAKT.fr | UIN : 16549830 [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.groupakt.fr http://www.fmsakt.fr | http://www.prospecttel.com Directeur général. ""Christian Seiler"" <[EMAIL PROTECTED]> a écrit dans le message de groupe de discussion : [EMAIL PROTECTED] Maintaining closures, see http://news.php.net/php.internals/39835 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
Dmitry Stogov wrote:
This behavior is already implemented in "improved" patch that I sent on
Saturday.
Thanks. Dmitry.
[snip]
What I mean is:
fopen("this_is_not_a_dir_but_a_file/../../../../../../../../etc/passwd",
"r");
works because of realpath() and PHP's wrapper.
[snip]
Does this change affect code like:
include "../file.php";
?
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
[EMAIL PROTECTED] escreveu:
On 11/08/2008, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
Hi!
Ideally someone would summarize the discussion (or maybe two people, one
from each "camp") and then we can have a vote. Make it an RFC or
OK, here it goes again:
When we adopt some syntax, especially syntax matching some other
language, we do not just introduce an otherwise meaningless sequence of
symbols to be learned by users. We introduce concepts, and we create
associative links with other languages. So, if we introduced the syntax
for namespaces that is used by C++ - i.e. braces, we would imply that it
has all the properties that C++ one has and that we encourage the usage
patterns that C++ users adopt. Namely, that namespaces can be nested,
that they are hierarchical, that namespaces can be used in any place in
the file, just for one function/class or even variable without any
influence on the surroundings, that using multiple namespaces in the
same file, along with global space, is completely OK.
So why the $%#$%& can't we use "package" if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
Added to that, braced namespaces would imply additional (and
unnecessary) level of hierarchy and indentation for most editors and
code formatters.
[snip]
With all that, there's not one thing that syntax with {} enables us to
do and that is not possible to do right now (and that we want to do :).
Well. I do want that indentation if I ever will be dumb enough to have
multiple namespace in the same file..
There is only one thing I could care less about than consistency, and
that is Windows.
Its not about consistency for me. Its about that little gut feeling you have.
To me it looks, and feels, much more like a namespace when you wrap it
in a namespace block. To me its more natural syntax.
-Hannes
IMHO it doesn't make sense to have {} around namespaces if PHP
recommends (imposes?) 1 namespace per file. I personally prefer the more
C++-like way, described by Stanislav, where you can do pretty much
anything namespace-wise. But if PHP is sticking to the prior, { } just
looks wrong to me.
--
Rodrigo Saboya
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Stanislav Malyshev wrote:
> When we adopt some syntax, especially syntax matching some other
> language, we do not just introduce an otherwise meaningless sequence of
> symbols to be learned by users. We introduce concepts, and we create
> associative links with other languages. So, if we introduced the syntax
> for namespaces that is used by C++ - i.e. braces, we would imply that it
> has all the properties that C++ one has and that we encourage the usage
> patterns that C++ users adopt. Namely, that namespaces can be nested,
> that they are hierarchical, that namespaces can be used in any place in
> the file, just for one function/class or even variable without any
> influence on the surroundings, that using multiple namespaces in the
> same file, along with global space, is completely OK.
Except that C++ is not the only language that uses this syntax, nor is
it the only language with "baggage" associated with syntax - to say that
"I don't want braces because people would think it acts like C++" is as
silly as saying "I don't want the current namespace Foo; syntax because
people will think it acts like python"
The bottom line is this is new for PHP, and although there will be
confusion when it's first introduced (goodness, PHP5 had plenty of
teaching over __construct) eventually with good documentation people
will learn what to expect from the PHP version - and that it is not like
Java/C++/C#/Python/whatever
> With all that, there's not one thing that syntax with {} enables us to
> do and that is not possible to do right now (and that we want to do :).
> Only reason presented for this change is the misguided notion of
> "consistency", grounded in the belief that semantically different
> constructs must look the same, because that way they will be... well,
> "consistent".
Thinking as a new user...
How is
namespace foo;
semantically different from
class foo {}
or even
function foo {}
I'm defining something yes? With stuff basically "inside it". Yes an
oversimplification, but the strength of PHP has always been simple. So
why should it act differently? Why does it need different syntax to
define something?
> While similarity in function in many cases should produce
> similarity in looks, I believe there's substantial semantic difference
> between namespaces and classes or functions, enough to make them use
> different syntax, especially when it better fits the function namespaces
> are to serve in PHP.
And here is the difference - I don't believe there's substantial
semantic difference between namespaces or classes or functions, enough
to require teaching a new syntax.
But at the end of the day this is all personal preference. Just
remember the poor people who have to teach this to the new users ;)
Thanks,
Elizabeth Smith
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 11/08/2008, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>> Ideally someone would summarize the discussion (or maybe two people, one
>> from each "camp") and then we can have a vote. Make it an RFC or
>
> OK, here it goes again:
>
> When we adopt some syntax, especially syntax matching some other
> language, we do not just introduce an otherwise meaningless sequence of
> symbols to be learned by users. We introduce concepts, and we create
> associative links with other languages. So, if we introduced the syntax
> for namespaces that is used by C++ - i.e. braces, we would imply that it
> has all the properties that C++ one has and that we encourage the usage
> patterns that C++ users adopt. Namely, that namespaces can be nested,
> that they are hierarchical, that namespaces can be used in any place in
> the file, just for one function/class or even variable without any
> influence on the surroundings, that using multiple namespaces in the
> same file, along with global space, is completely OK.
So why the $%#$%& can't we use "package" if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
> Added to that, braced namespaces would imply additional (and
> unnecessary) level of hierarchy and indentation for most editors and
> code formatters.
> [snip]
> With all that, there's not one thing that syntax with {} enables us to
> do and that is not possible to do right now (and that we want to do :).
Well. I do want that indentation if I ever will be dumb enough to have
multiple namespace in the same file..
There is only one thing I could care less about than consistency, and
that is Windows.
Its not about consistency for me. Its about that little gut feeling you have.
To me it looks, and feels, much more like a namespace when you wrap it
in a namespace block. To me its more natural syntax.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
Ideally someone would summarize the discussion (or maybe two people, one
from each "camp") and then we can have a vote. Make it an RFC or
OK, here it goes again:
When we adopt some syntax, especially syntax matching some other
language, we do not just introduce an otherwise meaningless sequence of
symbols to be learned by users. We introduce concepts, and we create
associative links with other languages. So, if we introduced the syntax
for namespaces that is used by C++ - i.e. braces, we would imply that it
has all the properties that C++ one has and that we encourage the usage
patterns that C++ users adopt. Namely, that namespaces can be nested,
that they are hierarchical, that namespaces can be used in any place in
the file, just for one function/class or even variable without any
influence on the surroundings, that using multiple namespaces in the
same file, along with global space, is completely OK.
However, the usage that we want to promote in PHP is very different - we
want to encourage users to use one namespace per file (except for number
of hacks that basically pack multiple logical files into one physical
file), that namespace is to encompass big structured pieces of code and
not to be used in random in-and-out fashion.
Added to that, braced namespaces would imply additional (and
unnecessary) level of hierarchy and indentation for most editors and
code formatters. Of course, special exception can be programmed into
them to make namespace{} behave in a different way from all other
constructs having {} blocks, but this would be working on solving the
problem that we ourselves created, quite unnecessarily.
With all that, there's not one thing that syntax with {} enables us to
do and that is not possible to do right now (and that we want to do :).
Only reason presented for this change is the misguided notion of
"consistency", grounded in the belief that semantically different
constructs must look the same, because that way they will be... well,
"consistent". While similarity in function in many cases should produce
similarity in looks, I believe there's substantial semantic difference
between namespaces and classes or functions, enough to make them use
different syntax, especially when it better fits the function namespaces
are to serve in PHP.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hello Christian,
Monday, August 11, 2008, 8:43:31 PM, you wrote:
> Hi,
>> all submitted now. Thanks everyone for their help and especially
>> Christian for getting this started.
> Thanks for making my patch work after the modifications in
> zend_closures.c. I'm sorry I couldn't do it myself but I was kind of
> busy the last few days and the "simple fix" created memory leaks and I
> didn't want to post a knowingly broken patch.
> Anyway, there are still segfaults in the current version:
> $foo = function ($a) {};
> $o = new ReflectionMethod ($foo);
> $p = $o->getParameters ();
> unset ($o);
> $m = $p[0]->getDeclaringFunction ();
> Reflection::export ($m);
> $foo = function ($a) {};
> $p = new ReflectionParameter ($foo, 'a');
> $m = $p->getDeclaringFunction ();
> unset ($p);
> Reflection::export ($m);
> This is due to the fact that getParameters() / getDeclaringFunction()
> don't copy the fptr and fptr->common.function_name pointers if it's a
> closure. Here are patches for PHP 5.3 and HEAD that fix the problem:
> http://www.christian-seiler.de/temp/php/2008-08-11-reflection/segfaults-5.3.patch
> http://www.christian-seiler.de/temp/php/2008-08-11-reflection/segfaults-6.patch
> Also, the following test that I already posted should be added to
> PHP_5_2, PHP_5_3 and HEAD:
> http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflectionParameter_invalidMethodInConstructor.phpt
> The test already works for PHP_5_3 (since the fix for that was included
> in my original patch) but a segfault still occurs in PHP_5_2 and HEAD,
> my patch that I already posted fixes that problem for 5.2:
> http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-segfault-fix-5.2.patch
> My original patch also fixed the problem for HEAD, I readded that part
> to the above segfault patch for HEAD.
>> Also, it appears you do not have a cvs account, or did I overlook
>> something?
> No, I don't. Dmitry also mentioned that - should I request one?
Account approved and access granted. Please provide the function copying in
a function next to _free_function() and care for parameter info as well
(yeah sorry for the additional work). And then, happy submitting.
Also for your next patches (cvs di -N) allows to ship the new files in the
patch and (cvs di -Np) shows the context, which makes reading the patches
easier.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: cseiler
Maintaining closures, see http://news.php.net/php.internals/39835 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hello Christian,
Monday, August 11, 2008, 8:43:31 PM, you wrote:
> Hi,
>> all submitted now. Thanks everyone for their help and especially
>> Christian for getting this started.
> Thanks for making my patch work after the modifications in
> zend_closures.c. I'm sorry I couldn't do it myself but I was kind of
> busy the last few days and the "simple fix" created memory leaks and I
> didn't want to post a knowingly broken patch.
> Anyway, there are still segfaults in the current version:
> $foo = function ($a) {};
> $o = new ReflectionMethod ($foo);
> $p = $o->getParameters ();
> unset ($o);
> $m = $p[0]->getDeclaringFunction ();
> Reflection::export ($m);
> $foo = function ($a) {};
> $p = new ReflectionParameter ($foo, 'a');
> $m = $p->getDeclaringFunction ();
> unset ($p);
> Reflection::export ($m);
> This is due to the fact that getParameters() / getDeclaringFunction()
> don't copy the fptr and fptr->common.function_name pointers if it's a
> closure. Here are patches for PHP 5.3 and HEAD that fix the problem:
> http://www.christian-seiler.de/temp/php/2008-08-11-reflection/segfaults-5.3.patch
> http://www.christian-seiler.de/temp/php/2008-08-11-reflection/segfaults-6.patch
> Also, the following test that I already posted should be added to
> PHP_5_2, PHP_5_3 and HEAD:
> http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflectionParameter_invalidMethodInConstructor.phpt
> The test already works for PHP_5_3 (since the fix for that was included
> in my original patch) but a segfault still occurs in PHP_5_2 and HEAD,
> my patch that I already posted fixes that problem for 5.2:
> http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-segfault-fix-5.2.patch
> My original patch also fixed the problem for HEAD, I readded that part
> to the above segfault patch for HEAD.
>> Also, it appears you do not have a cvs account, or did I overlook
>> something?
> No, I don't. Dmitry also mentioned that - should I request one?
Yes, please do and the seg fix patch should have a function to do the
copying as it is not complete, so we can add to it as necessary.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hi,
all submitted now. Thanks everyone for their help and especially
Christian for getting this started.
Thanks for making my patch work after the modifications in
zend_closures.c. I'm sorry I couldn't do it myself but I was kind of
busy the last few days and the "simple fix" created memory leaks and I
didn't want to post a knowingly broken patch.
Anyway, there are still segfaults in the current version:
$foo = function ($a) {};
$o = new ReflectionMethod ($foo);
$p = $o->getParameters ();
unset ($o);
$m = $p[0]->getDeclaringFunction ();
Reflection::export ($m);
$foo = function ($a) {};
$p = new ReflectionParameter ($foo, 'a');
$m = $p->getDeclaringFunction ();
unset ($p);
Reflection::export ($m);
This is due to the fact that getParameters() / getDeclaringFunction()
don't copy the fptr and fptr->common.function_name pointers if it's a
closure. Here are patches for PHP 5.3 and HEAD that fix the problem:
http://www.christian-seiler.de/temp/php/2008-08-11-reflection/segfaults-5.3.patch
http://www.christian-seiler.de/temp/php/2008-08-11-reflection/segfaults-6.patch
Also, the following test that I already posted should be added to
PHP_5_2, PHP_5_3 and HEAD:
http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflectionParameter_invalidMethodInConstructor.phpt
The test already works for PHP_5_3 (since the fix for that was included
in my original patch) but a segfault still occurs in PHP_5_2 and HEAD,
my patch that I already posted fixes that problem for 5.2:
http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-segfault-fix-5.2.patch
My original patch also fixed the problem for HEAD, I readded that part
to the above segfault patch for HEAD.
Also, it appears you do not have a cvs account, or did I overlook
something?
No, I don't. Dmitry also mentioned that - should I request one?
Regards,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pspell tweak.
Was running pspell through g++ and found that a couple of error conditions
segments in pspell.c
are using the wrong cleanup methods. delete_pspell_manager() should be
delete_pspell_can_have_error()
-Phil.
--- pspell.c16 Jul 2008 18:35:41 - 1.61
+++ pspell.c11 Aug 2008 17:39:03 -
@@ -374,7 +374,7 @@
if(pspell_error_number(ret) != 0){
php_error_docref(NULL TSRMLS_CC, E_WARNING, "PSPELL couldn't open the dictionary. reason: %s",
pspell_error_message(ret));
- delete_pspell_manager(ret);
+ delete_pspell_can_have_error(ret);
RETURN_FALSE;
}
@@ -492,7 +492,7 @@
if(pspell_error_number(ret) != 0){
php_error_docref(NULL TSRMLS_CC, E_WARNING, "PSPELL couldn't open the dictionary. reason: %s",
pspell_error_message(ret));
- delete_pspell_manager(ret);
+ delete_pspell_can_have_error(ret);
RETURN_FALSE;
}
@@ -526,7 +526,7 @@
if(pspell_error_number(ret) != 0){
php_error_docref(NULL TSRMLS_CC, E_WARNING, "PSPELL couldn't open the dictionary. reason: %s",
pspell_error_message(ret));
- delete_pspell_manager(ret);
+ delete_pspell_can_have_error(ret);
RETURN_FALSE;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
I'll try to review it on Tuesday/Wednesday. Thanks. Dmitry. Lukas Kahwe Smith wrote: On 09.08.2008, at 17:42, Arnaud Le Blanc wrote: Hi, As Lucas said the patch seems ready now, could someone please review the patch for inclusion ? http://wiki.php.net/rfc/zendsignals Changes that have been made: - The patch has been ported to HEAD - The patch now supports multithreaded environments, and fixes many problems on non-windows platforms when enabled. - Extensions can use zend_signal() and zend_sigaction() so that all signals they declare will always be deferred in critical sections. PCNTL has been ported. - There is now a zend.signal_check ini entry so that the checks made in zend_signal_deactivate() can be done in non-debug builds. - Some code has been moved to process startup or global constructor routines. - The patch moves some HANDLE_BLOCK/UNBLOCK in zend_alloc to protect more code Yeah where do we stand with this patch? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
On 09.08.2008, at 17:42, Arnaud Le Blanc wrote: Hi, As Lucas said the patch seems ready now, could someone please review the patch for inclusion ? http://wiki.php.net/rfc/zendsignals Changes that have been made: - The patch has been ported to HEAD - The patch now supports multithreaded environments, and fixes many problems on non-windows platforms when enabled. - Extensions can use zend_signal() and zend_sigaction() so that all signals they declare will always be deferred in critical sections. PCNTL has been ported. - There is now a zend.signal_check ini entry so that the checks made in zend_signal_deactivate() can be done in non-debug builds. - Some code has been moved to process startup or global constructor routines. - The patch moves some HANDLE_BLOCK/UNBLOCK in zend_alloc to protect more code Yeah where do we stand with this patch? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hello guys, all submitted now. Thanks everyone for their help and especially Christian for getting this started. marcus Monday, August 11, 2008, 12:23:57 PM, you wrote: > Hello Dmitry, > Monday, August 11, 2008, 10:51:44 AM, you wrote: >> Hi Marcus, >> I committed the ZE part of your patch with exception for >> zend_error(E_ERROR, "Cannot destroy active lambda function"); >> Catching this error may cause memory corruption and crash. > Alright, didn't see that immediately. >> Thanks. Dmitry. > Thanks marcus >> Marcus Boerger wrote: >>> Hello Johannes, Christian, Felipe, >>> >>> and here 5.3 and 6.0 versions that also have most memleaks fixed. >>> >>> marcus >>> >>> Saturday, August 9, 2008, 12:34:59 AM, you wrote: >>> Hello Christian, Johannes, >>> Friday, August 8, 2008, 11:48:37 PM, you wrote: >>> > Hello Christian, >>> > I updated your patch for 5.3 due to recent changes. It works pretty fine > for me. Care to test again, especially with your new tests? Note that test > ext/reflection/tests/closures_001.phpt does not work for me and I have no > clue why. Well, besides that obviously the closure class no longer has an > entry for __closure, so it is more a question of how to know when to add > this. Also, it appears you do not have a cvs account, or did I overlook > something? >>> > Modified patch attached, including the updated reflection tests. >>> Ok, it is actually easy to fix, we just check whether the thing is a closure and add the method manually, done. New patch attached. >>> Johannes, this also adresses the switch from E_ERROR to E_RECOVERABLE_ERROR for the closure handlers. >>> best regards marcus >>> > Monday, August 4, 2008, 12:59:13 PM, you wrote: >>> >> Christian, >>> >> On Mon, 2008-08-04 at 11:33 +0400, Dmitry Stogov wrote: > http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-5.3.patch > > > http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-6.patch > >>> >> without applying and testing the patch: >>> >> - zend_hash_apply_with_arguments(&ce->function_table TSRMLS_CC, >> (apply_func_args_t) _addmethod, 3, &ce, return_value, filter); >> + zend_hash_apply_with_arguments(&ce->function_table TSRMLS_CC, >> (apply_func_args_t) _addmethod, 3, &ce, return_value, filter, >> intern->obj); >>> >> that looks a bit strange, probably you want 4 instead of 3 now? >>> >> johannes >>> >>> >>> >>> >>> > Best regards, > Marcus >>> >>> >>> Best regards, Marcus >>> >>> >>> >>> Best regards, >>> Marcus >>> > Best regards, > Marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 03.08.2008, at 14:26, Marcus Boerger wrote: 1) new keyword 'use'. Semantically it is the same as 'static' or 'global' so it should be used in the same location. 2) namespaces, either use 'package' and only one per file, or use 'namespace' with curly braces. Read this as be consistent with other languages and even if one or two people do not like it the two main languages out there which have it are Java which goes with the former and C++ which does the latter. Please chose and not mix it. Also our mix is a nightmare when developing code. If we feel we have to keep the keyword 'namesapce' but cannot have curly braces, than I suggest we disallow multiple namespace per file. And there is no technical reason and surely no other reason whatsoever to not have curly braces. If there is then we either fix that or went with the wrong approach. 3) __invokable, see Etiene's mail AFAIK 3) is resolved? So it seems to me like 1) and 2) have gone back and forth between people enough. We have also agreed that multiple namespaces per file are a necessary feature to support. But now the question is if we are going to change anything or not. Ideally someone would summarize the discussion (or maybe two people, one from each "camp") and then we can have a vote. Make it an RFC or whatever. But this is definitely the last time we are going to vote on the curly brackets stuff for namespaces in 5.3. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hello Dmitry, Monday, August 11, 2008, 10:51:44 AM, you wrote: > Hi Marcus, > I committed the ZE part of your patch with exception for > zend_error(E_ERROR, "Cannot destroy active lambda function"); > Catching this error may cause memory corruption and crash. Alright, didn't see that immediately. > Thanks. Dmitry. Thanks marcus > Marcus Boerger wrote: >> Hello Johannes, Christian, Felipe, >> >> and here 5.3 and 6.0 versions that also have most memleaks fixed. >> >> marcus >> >> Saturday, August 9, 2008, 12:34:59 AM, you wrote: >> >>> Hello Christian, Johannes, >> >>> Friday, August 8, 2008, 11:48:37 PM, you wrote: >> Hello Christian, >> I updated your patch for 5.3 due to recent changes. It works pretty fine for me. Care to test again, especially with your new tests? Note that test ext/reflection/tests/closures_001.phpt does not work for me and I have no clue why. Well, besides that obviously the closure class no longer has an entry for __closure, so it is more a question of how to know when to add this. Also, it appears you do not have a cvs account, or did I overlook something? >> Modified patch attached, including the updated reflection tests. >> >>> Ok, it is actually easy to fix, we just check whether the thing is a >>> closure and add the method manually, done. New patch attached. >> >>> Johannes, this also adresses the switch from E_ERROR to E_RECOVERABLE_ERROR >>> for the closure handlers. >> >>> best regards >>> marcus >> Monday, August 4, 2008, 12:59:13 PM, you wrote: >> > Christian, >> > On Mon, 2008-08-04 at 11:33 +0400, Dmitry Stogov wrote: http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-5.3.patch http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-6.patch >> > without applying and testing the patch: >> > - zend_hash_apply_with_arguments(&ce->function_table TSRMLS_CC, > (apply_func_args_t) _addmethod, 3, &ce, return_value, filter); > + zend_hash_apply_with_arguments(&ce->function_table TSRMLS_CC, > (apply_func_args_t) _addmethod, 3, &ce, return_value, filter, > intern->obj); >> > that looks a bit strange, probably you want 4 instead of 3 now? >> > johannes >> >> >> >> >> Best regards, Marcus >> >> >> >>> Best regards, >>> Marcus >> >> >> >> Best regards, >> Marcus >> Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP5.3+ win32 snaps latest file missing.
hi, On Mon, Aug 11, 2008 at 11:11 AM, Richard Quadling <[EMAIL PROTECTED]> wrote: > Hi. > > Whilst you can download the most recent file from snaps.php.net, the > latest file has always been named as php5.3-win32-latest.zip. Which > means you don't need to know when the latest build was. Recently the > latest file is missing. The filename appears in the list at > http://snaps.php.net/win32, but doesn't download. > > Output from wget ... My fault, while updating to the new snap scripts (which are now in cvs under http://cvs.php.net/php-internals-win), I forgot to create symlink for -latest. It will be fixed today. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 Snapshots for PECL V5.3.x stalled.
hi, On Mon, Aug 11, 2008 at 10:59 AM, Richard Quadling <[EMAIL PROTECTED]> wrote: > Hi. > > It may be known or not, but the Win32 PECL snapshots was last > successfully built on (as at 2008/08/11 10:00 AM GMT) > > pecl5.3-win32-latest.zip07-Aug-2008 08:45 4.1M > pecl5.3-win32-200808070430.zip 07-Aug-2008 08:45 4.1M They are not built at all. We removed the link in CVS but somehow the rsync cron does not work anymore on the snaps.php.net box since last day. Derick being in hollidays, I can't fix it. The PECL packages will be back online in pecl.php.net as soon as possible and using releases. Cheers. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (67 total -- which includes 26 feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[*Regular Expressions]= 44923 Open ereg works differently in PHP 6.0 unicode.semantics=on ===[*Unicode Issues]== 44868 Open Replaces UTF-8 symbol with incorrect symbol ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib ouptut compression is on ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy 44043 Open Enforcing a method without specifying the arguments ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 45246 Open make error after ./configure --with-mysql ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir,readdir) 42110 Open fgetcsv doesn't handle ""\n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n 45585 Open fread() return value for EOF inconsistent between PHP 5 and 6 ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[MySQL related] 44076 Open mysql_result returns nothing with blob ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket 42079 Open pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated) ===[Performance problem]== 42528 Open Out of "char"(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Reproducible crash]=== 45107 Open setting ext_dir to "./" (and other ini settings) causes apache crash ===[Scripting Engine problem]= 33487 Assigned Memory allocated for objects created in object methods is not released 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe ===[Session related]== 44860 Open session_encode fails for php_binary serialiser ===[Strings related]== 44075 Verified strtok misbehaving 45566 Open Strict comparision on $_SERVER values fail ===[Unicode Engine related]=== 45248 Open Shfift_JIS encoded characters in PHP script cause an error. ===[Unknown/Other Function]=== 45087 Open Illegal or truncated character in input ===[URL related]== 45602 Open urlencode/urldecode should use ASCII encoding ===[XML related]== 45022 Open Can't get php6 snap to ./configure on mac, fails at libxml2 ===[XSLT related]= 38218 Assigned php:functionString tries t
[PHP-DEV] PHP5.3+ win32 snaps latest file missing.
Hi. Whilst you can download the most recent file from snaps.php.net, the latest file has always been named as php5.3-win32-latest.zip. Which means you don't need to know when the latest build was. Recently the latest file is missing. The filename appears in the list at http://snaps.php.net/win32, but doesn't download. Output from wget ... --10:07:10-- http://snaps.php.net/win32/php5.3-win32-latest.zip => `D:\Personal Files\Software\PHP\Latest Versions\php5.3-win32-latest.zip' Resolving snaps.php.net... 128.39.198.38 Connecting to snaps.php.net|128.39.198.38|:80... connected. HTTP request sent, awaiting response... 404 Not Found 10:07:10 ERROR 404: Not Found. Regards, Richard Quadling. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Win32 Snapshots for PECL V5.3.x stalled.
Hi PHP 5.2 DEV Win - 06-Aug-2008 04:20 UTC best regards holo ""Richard Quadling"" <[EMAIL PROTECTED]> escreveu na mensagem news:[EMAIL PROTECTED] > Hi. > > It may be known or not, but the Win32 PECL snapshots was last > successfully built on (as at 2008/08/11 10:00 AM GMT) > > pecl5.3-win32-latest.zip07-Aug-2008 08:45 4.1M > pecl5.3-win32-200808070430.zip 07-Aug-2008 08:45 4.1M > > Regards, > > Richard. > -- > - > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Win32 Snapshots for PECL V5.3.x stalled.
Hi. It may be known or not, but the Win32 PECL snapshots was last successfully built on (as at 2008/08/11 10:00 AM GMT) pecl5.3-win32-latest.zip07-Aug-2008 08:45 4.1M pecl5.3-win32-200808070430.zip 07-Aug-2008 08:45 4.1M Regards, Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Closures and reflection improvements
Hi Marcus, I committed the ZE part of your patch with exception for zend_error(E_ERROR, "Cannot destroy active lambda function"); Catching this error may cause memory corruption and crash. Thanks. Dmitry. Marcus Boerger wrote: Hello Johannes, Christian, Felipe, and here 5.3 and 6.0 versions that also have most memleaks fixed. marcus Saturday, August 9, 2008, 12:34:59 AM, you wrote: Hello Christian, Johannes, Friday, August 8, 2008, 11:48:37 PM, you wrote: Hello Christian, I updated your patch for 5.3 due to recent changes. It works pretty fine for me. Care to test again, especially with your new tests? Note that test ext/reflection/tests/closures_001.phpt does not work for me and I have no clue why. Well, besides that obviously the closure class no longer has an entry for __closure, so it is more a question of how to know when to add this. Also, it appears you do not have a cvs account, or did I overlook something? Modified patch attached, including the updated reflection tests. Ok, it is actually easy to fix, we just check whether the thing is a closure and add the method manually, done. New patch attached. Johannes, this also adresses the switch from E_ERROR to E_RECOVERABLE_ERROR for the closure handlers. best regards marcus Monday, August 4, 2008, 12:59:13 PM, you wrote: Christian, On Mon, 2008-08-04 at 11:33 +0400, Dmitry Stogov wrote: http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-5.3.patch http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-6.patch without applying and testing the patch: - zend_hash_apply_with_arguments(&ce->function_table TSRMLS_CC, (apply_func_args_t) _addmethod, 3, &ce, return_value, filter); + zend_hash_apply_with_arguments(&ce->function_table TSRMLS_CC, (apply_func_args_t) _addmethod, 3, &ce, return_value, filter, intern->obj); that looks a bit strange, probably you want 4 instead of 3 now? johannes Best regards, Marcus Best regards, Marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
On 11.08.2008, at 09:31, Dmitry Stogov wrote: The failure of realpath_basic-win32.phpt is expected, as behavior of realpath() became the same as on Linux (slashes after regular file name are not allowed). Lets make extra sure that when you commit these kinds of platform unifications, that you use the [DOC] tag so that things get documented (and adding a note to the 5.3 upgrading scratch pad [1] would also be nice). regards, Lukas Kahwe Smith [EMAIL PROTECTED] [1] http://wiki.php.net/doc/scratchpad/upgrade/53 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
Hi Pierre,
Thank you for feedback.
You are definitely right about FindClose().
The failure of realpath_basic-win32.phpt is expected, as behavior of
realpath() became the same as on Linux (slashes after regular file name
are not allowed).
I wasn't able to reproduce realpath_basic2.phpt failure (may be because
I added missing FindClose()).
Thanks. Dmitry.
Pierre Joye wrote:
hi Dmitry,
On Sat, Aug 9, 2008 at 5:28 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
The improved patch fixes all the issues I found during testing.
However I wasn't able to test it on NETWARE and on Solaris with relative
paths.
Please test it as much as possible.
I run the test suite and the results can be seen here:
http://phpfi.com/341752
There is two failing for real path (Server 2008, Vista 64 and XP (32 and 64)):
Test realpath() function: basic functionality
[C:\Users\pierre\Documents\php-sdk\vc9\x86\php_5_3\ext\standard\tests\file\realpath_basic-win32.phpt]
realpath() with relative directory
[C:\Users\pierre\Documents\php-sdk\vc9\x86\php_5_3\ext\standard\tests\file\realpath_basic2.phpt]
Some other may fail because of a change in realpath behavior. I will
run them again without the patch and post again the affected tests.
I'm going to commit it on Tuesday in case of no objections.
A FindClose is missing:
+#ifdef TSRM_WIN32
+ if (save && (hFind = FindFirstFile(path, &data)) ==
INVALID_HANDLE_VALUE) {
if (use_realpath == CWD_REALPATH) {
- return 1;
+ /* file not found */
+ return -1;
}
.
+ if (save) {
+ directory = (data.dwFileAttributes &
FILE_ATTRIBUTE_DIRECTORY) != 0;
+ if (is_dir && !directory) {
+ /* not a directory */
FindClose(hFind);
+ return -1;
+ }
+ }
+ tmp = tsrm_do_alloca(len+1, use_heap);
+ memcpy(tmp, path, len+1);
+#elif defined(NETWARE)
+ save = 0;
+ tmp = tsrm_do_alloca(len+1, use_heap);
+ memcpy(tmp, path, len+1);
#else
Cheers,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
