On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably elaborate. I
believe if the collector kicks in there'll also be a bit of a slowdown
but my main concern is to be able to turn it off because of stability.
As you can see with the update patch it
On 06.12.2007 11:21, Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably elaborate. I
believe if the collector kicks in there'll also be a bit of a slowdown
but my main concern is to be able to turn it off because of
Antony Dovgal schrieb:
To be honest, I can't see any crashes using standard PHP test suite.
Does the standard PHP test suite contain PHP code with reference cycles?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277
On Thu, 6 Dec 2007, Antony Dovgal wrote:
On 06.12.2007 11:21, Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably elaborate. I
believe if the collector kicks in there'll also be a bit of a slowdown
but my main concern
Derick Rethans wrote:
On Tue, 4 Dec 2007, Andi Gutmans wrote:
To clarify I meant there's a tri-state (not compiled in, compiled in
but collection turned off, compiled in but collection turned on). My
recommendation was to always compile it in but to keep collection
turned off by default.
The GC patch passes the whole php test-suite with the same bugs.
The fact that it crashes on some script doesn't mean that the patch
doesn't actually work.
Thanks. Dmitry.
Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably
On Thu, 6 Dec 2007, Dmitry Stogov wrote:
Derick Rethans wrote:
On Wed, 5 Dec 2007, Andi Gutmans wrote:
Yes that's basically true although Dmitry can probably elaborate.
I believe if the collector kicks in there'll also be a bit of a
slowdown but my main concern is to be able to
Hi!
Yes, that's my point - 3X faster include opcode is not 3X faster code.
Of course if you do this opcode a lot of times, it would be somewhat
slower than if you do this opcode just one time. However, the question
is how it would influence the whole application?
I didn't say that the code
Hi!
Especially in a framework context there a lot of options how you can
make things more convenient, with
convention over configuration for example. In the end it might turn out
that a developer doesn't have
to type class names that often anymore and the length of such a name
gets less
Am 06.12.2007 um 04:22 schrieb Jeremy Privett:
I know I just finished praising you just some hours ago, Stas, but
I'm going to have to step in and agree with Larry on this one. It
really doesn't make sense for there to be no braces for namespaces
(especially if you're going to allow
Hello Roman, Stas,
even more so you want to have it as close as possible so that one can in
fact get a clue what is going on manually. And if only generators use that
stuff - well it doesn't matter to a generator if it has to write braces or
not. We create syntax for humans - otherwise we would
Did this topic end nowhere?
Isn't some fix here better than no fix?
class-constants are currently compile-time constants and letting them
use constants from classes defined in other files will move them to
run-time constants (because php has ambiguity-feature of
conditional-loading), so,
I don't agree with that. I think multiple namespaces per file would be
fine with the current syntax as this is a feature that would not be
used by that many people and if it's used it's not for development
purposes (who wants to read a class bundle with no comments,
linebreaks etc.?) and
+1. If we allow multiple namespaces per file, then braces are an
absolute must for consistency IMO.
I do not see any relation between consistency and braces.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP
If a namespace can be valid for a portion of code in one file, then it
should be possible to use the same syntax as for all other blocks in
PHP. You wouldn't suggest this:
class Foo;
public function zomg() {}
class Bar;
public function lolz() {}
would you? Not the same thing, but you
would you? Not the same thing, but you get the idea.
Exactly: not the same thing. Only reason I see to consider allowing
multiple namespaces per file is performance reasons.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL
I agree that braces are the way to go. Otherwise it's to easy to lose
track of what namespace you're working with.
If a namespace can be valid for a portion of code in one file, then it
should be possible to use the same syntax as for all other blocks in
PHP. You wouldn't suggest this:
class
I agree that braces are the way to go. Otherwise it's to easy to lose
track of what namespace you're working with.
This is simple - you always have one namespace per file.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL
Just a thought... You know the whole thing about bundling into one file
improving performance. People do this when they have upwards of 20 classes
being included per request. I bet that most of the time these classes are a
part of a framework / something that would be a part of common name space
On Dec 6, 2007, at 7:08 PM, Michael McGlothlin wrote:
PHP already has the bad habit for many programmers to write totally
unreadable code. It's darn near as bad as Perl in that area. No
reason to make it worse.
And you really think not allowing multiple namespaces in a file will
improve
Then it's best to not allow multiple namespaces for file. If you're not
That's what I was telling everybody for about a month now :)
going to keep the syntax clean then don't do it. PHP already has the bad
The syntax is very clean, but you are not supposed to use it.
habit for many
PHP already has the bad habit for many programmers to write totally
unreadable code. It's darn near as bad as Perl in that area. No
reason to make it worse.
And you really think not allowing multiple namespaces in a file will
improve that? I don't think so. These people will continue to
programmer or a Python programmer. You can have nasty Python code but it
takes far more effort than with Perl code. PHP is somewhere in the
I don't think writing bad code takes any special effort in any language.
Writing good code takes effort, and it is the fact with any language -
because
Begin forwarded message:
From: Roman Borschel [EMAIL PROTECTED]
Date: December 6, 2007 7:29:19 PM GMT+01:00
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Namespace
Thats true, however frameworks tend to have a lot of different
namespaces. Just take a look at the Zend Framework.
Roman
On
I agree that braces are the way to go. Otherwise it's to easy to lose
track of what namespace you're working with.
This is simple - you always have one namespace per file.
Then it's best to not allow multiple namespaces for file. If you're not
going to keep the syntax clean then don't do it.
On Dec 6, 2007 12:05 PM, Gergely Hodicska [EMAIL PROTECTED] wrote:
Hi!
Yes, that's my point - 3X faster include opcode is not 3X faster code.
Of course if you do this opcode a lot of times, it would be somewhat
slower than if you do this opcode just one time. However, the question
is
You have a point, however it is not always this simple. Some
applications have classes/functions that are not necessarily gathered in
order by their namespaces. It would be a nightmare to try to organize
and then bundle these functions and classes together dynamically into
different files by
Hi Derick,
I've been thinking a *lot* about your provocative email in the past
couple of days, and have come to a different conclusion from my original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use).
Holy wow. That was fantastic! Not to downplay anything that Stas and the
other developers have done -- because let's face it, they've done a
fantastic job themselves -- you have definitely risen above and beyond the
call of duty and really come up with some very compelling counter-arguments.
This
Hi Greg,
Thanks for the detailed thoughts.
Guides examples regarding use-cases will definitely be important for the
community. I am sure just this email has already been very helpful to many on
this list.
Andi
-Original Message-
From: Gregory Beaver [mailto:[EMAIL PROTECTED]
Sent:
Hi Greg,
I'm speechless. All of your points are sound and you've obviously done
your homework, here. I agree with Ken in that you've gone above and
beyond on the research and arguments you've presented here.
Excellent work and a hearty +1 to all of your points.
Jeremy
Gregory Beaver wrote:
31 matches
Mail list logo
