On Tue, 4 Dec 2007, Larry Garfield wrote:
1) use MyDate as DateTime. I believe Greg pointed out the solution here.
When PHP 5.5 is released and adds its own Whatever class, you just do the
following:
namespace me;
use Whatever as LegacyWhatever;
class Whatever{}
It's a one-line
On Dec 5, 2007, at 12:52 AM, Robert Lemke wrote:
Hi Derick,
I also agree with your arguments - beautifying class names is not
reason enough for
introducing namespaces.
On 04.12.2007 at 23:16 Derick Rethans wrote:
4. What is wrong with simple prefixes in the first place? Both
PEAR_*,
Rasmus Lerdorf skrev:
It may not be the browser that misses the script tag. It may be the
developer.
To make things clear. My intention was not to question the value in
escaping data or even to give an opinion whatsoever about Sara's patch.
I was only replying to Alexey's notion that one
Keryx Web wrote:
Alexey Zakhlestin skrev:
I think I understand what the use-case is…
If the browser doesn't know anything about script tag, it is
supposed to interpret it's contents as html… In which case, html-tags
which appear in javascript code will actually become active ones
And in
As a developer and member of the community, the following is my two-cents on
the subject:
On Dec 4, 2007 5:16 PM, Derick Rethans [EMAIL PROTECTED] wrote:
1. As it is impossible to do use XXX as NativeClass we get to the
point where we'd have to namespace new internal native classes
Autoload would work exactly the same with namespaces, just do a
str_replace and replace :: with _.
On Wed, 2007-12-05 at 09:52 +0100, Robert Lemke wrote:
Hi Derick,
I also agree with your arguments - beautifying class names is not
reason enough for
introducing namespaces.
On 04.12.2007
Namespace support is for people who didn't name their classes/functions
properly.
Here's a claim so weird I don't know how to parse it.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime
Anyway, I'm not against namespaces but the way they are planned to be
implemented currently I'm not really excited about them either.
So you are proposing to improve them how?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL
some people like a misguided implementation of namespaces. The idea of
namespaces is to prevent collisions in USER land code, not turning
internal PHP classes into a pile of goo.
Yes, idea of namespaces is not to turn PHP classes into a pile of goo.
But what's your point?
I don't quite
On Wed, 2007-12-05 at 09:34 -0800, Stanislav Malyshev wrote:
Namespace support is for people who didn't name their classes/functions
properly.
Here's a claim so weird I don't know how to parse it.
I think you're confusing parsing for grokking. Namespace support is
merely candy coating for
On 05.12.2007, at 17:43, Sebastian Bergmann wrote:
Matthias Pigulla schrieb:
Given that it was technically feasible, (future) core classes should
be in namespaces as well.
Or
- Introduce namespaces in PHP 6
- Move all functions and classes that are now global into
(per-extension)
Matthias Pigulla schrieb:
Given that it was technically feasible, (future) core classes should
be in namespaces as well.
Or
- Introduce namespaces in PHP 6
- Move all functions and classes that are now global into
(per-extension) namespace(s)
- Add a fallback mechanism that looks
Von: Steph Fox [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 5. Dezember 2007 02:34
import nstest::test as whatever;
This works in the global space, right? Now along comes, say, Pierre or
Derick or Marcus with this class they just have to add to an existing
(non-namespaced) core
Dmitry Stogov wrote:
In general this patch will use more memory.
(4 bytes more for each heap allocated zval).
The only advantage is automatic cycle collection, but most web
applications doesn't make cycles.
Could it be that this code should only be enabled for the CLI sapi?
That is where I
On Tue, 27 Nov 2007, Wez Furlong wrote:
All will be revealed soon.
Just wondering what sort of timeframe you mean with soon... any idea?
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development
I agree. If the solution to this is to start adding prefixes to the aliased
names, then namespaces lose part of their purpose.
The solution is not to import everything in global space. If you must,
namespaces as such won't help you avoid collisions. The purpose of
namespaces is *NOT* (I don't
2007/12/5, Robert Cummings [EMAIL PROTECTED]:
On Wed, 2007-12-05 at 09:34 -0800, Stanislav Malyshev wrote:
Namespace support is for people who didn't name their
classes/functions
properly.
Here's a claim so weird I don't know how to parse it.
I think you're confusing parsing for
To summarize the patch lead to approx. 5% slowdown and 3% memory
overhead for typical applications (as always, you mileage may vary
depending on your system's architecture and OS although my guesstimate
is that you will see even worse results in a 64bit environment).
Does that slowdown result
The second is the one I'm trying to address, wherein data that belongs
in a JS parsing context may (coincidentally) contain HTML parsable data.
For *whatever* reason, this data may accidently be echoed outside of a
JS context, or a parsing/rendering error may lead to the browser
switching
payload to innerHTML, you are hosed. Using the \u syntax, even if you
mess up and that blob of data finds its way to an innerHTML, nothing
nasty can happen. Basically this is a more robust context-protected way
I'm not sure this is correct - if you just write something like:
script
var =
Stanislav Malyshev wrote:
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
What's 100% right? Any proposals (besides braces)?
I'll take a guess that you put alot of effort into the namespace implementation,
that's the only reason I can think of that
On Dec 5, 2007 12:54 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
(I don't know how to make it more clear - should I
use blinking text, flash graphics and pictures of dancing girls/boys in
bikinis?)
Stas, that is immature, rude, and completely uncalled for; fine, you are
frustrated with
This would be a good idea, if implemented with a compatibility layer to
be removed later.
::php
::str
::arr
::ob
etc
::ext
::mysql
::mysqli
Userland code can then use a namespace such as ::app, or just use the
global namespace with no
I think you're confusing parsing for grokking. Namespace support is
merely candy coating for naming conventions. Namespaces have the same
Yes, and PHP is merely a candy coating for shoving electrons around
silicon chips. Makes as much sense. Yes, namespaces deal with naming.
No, namespace in
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
Stanislav Malyshev wrote:
some people like a misguided implementation of namespaces. The idea
of namespaces is to prevent collisions in USER land code, not turning
internal PHP classes into a pile of goo.
+1. Maybe PHP 6, as Sebastian suggested.
David
Am 05.12.2007 um 19:22 schrieb Jochem Maas:
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
Stanislav Malyshev wrote:
some people like a misguided implementation of namespaces. The
idea
of namespaces
I didn't put any work in here and I agree with him 100%. Namespaces have
been incredibly useful for me. Now that I'm using them I would not want
to do without them.
As far as bundling, my application (over 11,000 lines now) did use a
bundling feature that I can no longer use. It would be very
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.
That's totally fine
And I already do that within my code without namespaces.
You can also do anything in code without classes, so what? With classes
it works better, and with namespaces it is yet better.
Yes, but the main push for namespaces is to solve the problem of
colliding names.
You can not solve this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Rasmus Lerdorf wrote:
We should probably have done it this way right from
the beginning, but since we didn't and since we don't really want to
deal with the potential BC issues of changing working code, we have to
add it as an option at this
On Wed, 2007-12-05 at 10:04 -0800, Stanislav Malyshev wrote:
namespaces bring to the table beyond that, is the ability to
shorthand the class names within the namespace... as I said candy
coating.
You can say it as many times as you like, it doesn't make it true. It
is the capability
On Dec 5, 2007 12:04 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
collision problems that class naming and function naming have. Only
Only if you insist on *not* using the namespaces to solve collision
problems. For the 1001th time - you can not expect to put all names into
global space
Stas, that is immature, rude, and completely uncalled for; fine, you are
frustrated with our questions and arguments. Comments like this creates
What I'm frustrated with is not questions and arguments, but the same
misconceptions about namespaces repeated over and over after it was
explained
On Wed, 5 Dec 2007 09:55:40 +0100 (CET), Derick Rethans [EMAIL PROTECTED]
wrote:
On Tue, 4 Dec 2007, Larry Garfield wrote:
1) use MyDate as DateTime. I believe Greg pointed out the solution
here.
When PHP 5.5 is released and adds its own Whatever class, you just do
the
following:
payload to innerHTML, you are hosed. Using the \u syntax, even if you
mess up and that blob of data finds its way to an innerHTML, nothing
nasty can happen. Basically this is a more robust context-protected way
I'm not sure this is correct - if you just write something like:
script
var =
implementation [details] not the concept. I believe that the implementation
needs a little ironing out ... what's the harm in taking the time to do this?
or at least taking the time to let consensus take hold?
No harm, but we will have multiple namespaces per file figured out
pretty soon, and
Hi Nate,
Only if you insist on *not* using the namespaces to solve collision
problems. For the 1001th time - you can not expect to put all names into
global space and have the language by some magic to sort it out and go
both ways. One name can mean only one thing, namespaces or not.
Namespaces
Hi Larry,
Am 05.12.2007 um 18:09 schrieb Larry Garfield:
Finally, another important reason for us to not use namespaces is the
lack of available refactoring tools.
Imagine you want to rename a class T3_Cool_Fancy_Stuff to
T3_Cool_Fancy_Tool. A global search / replace
and renaming the class
On Dec 5, 2007 3:03 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
What I'm frustrated with is not questions and arguments, but the same
misconceptions about namespaces repeated over and over after it was
explained multiple times it is just not what namespaces are and how they
are supposed
I think I may be in way over my head on this one... After reading those
pages, I still have no clue what to do. This is the first time I've
actually looked at PHP source code...
David Coallier wrote:
On Dec 1, 2007 10:45 AM, Michael Eshom [EMAIL PROTECTED] wrote:
I should also mention
Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a
gc_go_find_cycles()
function? Would that significantly improve the above numbers?
Yes, that would be
Stanislav Malyshev wrote:
based on the reactions it has been recieving I would disagree. that is
not to say
that completing the baking process would not result in a wonderful
functional addition
to the language. I'm just advocating putting it on the backburner
until the cooking
time is
I agree, I also see this as critical in large applications. The current
implementation may have some problems, yes, but it's not hurting anyone
who's not using namespaces.
The minor issues around namespaces can be worked out in due time, but I
think it would be a huge mistake to drop the whole
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.
Do I understand it right that being compiled in, turned on and
On Wed, 5 Dec 2007, Matthias Pigulla wrote:
To summarize the patch lead to approx. 5% slowdown and 3% memory
overhead for typical applications (as always, you mileage may vary
depending on your system's architecture and OS although my guesstimate
is that you will see even worse results in
based on the reactions it has been recieving I would disagree. that is not to
say
that completing the baking process would not result in a wonderful functional
addition
to the language. I'm just advocating putting it on the backburner until the
cooking
time is complete.
So far I have yet to
Stanislav Malyshev wrote:
implementation [details] not the concept. I believe that the
implementation
needs a little ironing out ... what's the harm in taking the time to
do this?
or at least taking the time to let consensus take hold?
No harm, but we will have multiple namespaces per file
On Wed, 5 Dec 2007, Matthias Pigulla wrote:
Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a
gc_go_find_cycles()
function? Would that
Stanislav Malyshev skrev:
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
What's 100% right? Any proposals (besides braces)?
Actually I did mention an alternative a while ago, and that would be to
learn from ECMAScript 4. This is from John Resigs
On Wed, 2007-12-05 at 10:01 -0600, Brian Moon wrote:
Dmitry Stogov wrote:
In general this patch will use more memory.
(4 bytes more for each heap allocated zval).
The only advantage is automatic cycle collection, but most web
applications doesn't make cycles.
Could it be that this
On Mon, 3 Dec 2007, Andi Gutmans wrote:
The revised patch has the following advantages:
- It fixes several crash bugs
So far, my tests only see new crash bugs... :/
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2ba1140c6930 (LWP 21108)]
0x008be4fe in
On Wed, 5 Dec 2007, Stanislav Malyshev 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.
Do I
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
What's 100% right? Any proposals (besides braces)?
apparently people keep 'flogging this horse to death' because they are not
convinced by your wisdom with regard to this decision - they may be idiots (me
Hm. After you made your original reply to me, I went to PHP's website
and found namespaces in the manual:
http://www.php.net/manual/en/language.namespaces.php, hence my reply.
Ah. I didn't see it there last time I checked. All hail to docs team,
great work! Must have missed when it was
The implementation as it is now works. It's functional, and useful.
Minor issues like import/use can be worked out when necessary, but for
now I see this as something that can be released (provided that most of
the bugs are worked out). Multiple namespaces per file is the only thing
I see as a
Hi Ronald,
Am 05.12.2007 um 11:08 schrieb Ronald Chmara:
http://www.phpbuilder.com/lists/php-documentation-list/
2001071/0109.php
I, for one, would not enjoy typing out:
T3_MyPackage_MySubPackage_Controller_DefaultController any more
often than I absolutely *had* to.
well, in a way I
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 seems performance is quite good.
Anyway will
On Wed, 5 Dec 2007 11:48:58 +0100, Robert Lemke [EMAIL PROTECTED] wrote:
Finally, another important reason for us to not use namespaces is the
lack of available refactoring tools.
Imagine you want to rename a class T3_Cool_Fancy_Stuff to
T3_Cool_Fancy_Tool. A global search / replace
and
I don't understand what are you going to demonstrate with this example.
Did you try to run it?
It produces error as expected.
DOMDocument() in your example is a user-space class that is not related
to internal ext/dom class. If you like to use internal class that is
overriden in namespace you
On Tue, 4 Dec 2007, Gregory Beaver wrote:
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
No, use should not allow this. Take the following example:
?php
Hello Steph,
Wednesday, December 5, 2007, 2:33:47 AM, you wrote:
However, in the global scope (no namespace) it would fail. This is a
bug that is easily fixed. use should allow re-aliasing of global
classes, and I could provide a very easy fix.
This is not a bug - since there you work
In general this patch will use more memory.
(4 bytes more for each heap allocated zval).
The only advantage is automatic cycle collection, but most web
applications doesn't make cycles.
Dmitry.
Guilherme Blanco wrote:
I want to put my 2 cents, but before make any comment, I'm interested
to
Hi Derick,
I also agree with your arguments - beautifying class names is not
reason enough for
introducing namespaces.
On 04.12.2007 at 23:16 Derick Rethans wrote:
4. What is wrong with simple prefixes in the first place? Both PEAR_*,
Zend_*, ezc*, and ezp* are perfectly acceptable
On Tue, 4 Dec 2007, Stanislav Malyshev wrote:
following some discussions on the list (re. multiple namespaces in file) as
well as a short discussion on IRC regarding not being able to do
use yeti::xml::DomDocument as DomDocument; - I do not see any point in
having
You mean like ability
On 05.12.2007, at 04:28, Steph Fox wrote:
I'd like wildcard support too... and support for multiple namespaces
per file (for bundling only)... but neither of those are complete
deal-breakers in my eyes. Protection from naming collisions, is.
FULLACK, the good news is that i accidently
Hi Sam,
Am 05.12.2007 um 14:51 schrieb Sam Barrow:
Autoload would work exactly the same with namespaces, just do a
str_replace and replace :: with _.
hmm, and what about this (please correct me if I'm wrong):
?php
namespace T3::MyPackage::Controller;
class Special extends Default {
}
?
On Wednesday 05 December 2007, Stanislav Malyshev wrote:
implementation [details] not the concept. I believe that the
implementation needs a little ironing out ... what's the harm in taking
the time to do this? or at least taking the time to let consensus take
hold?
No harm, but we will
Larry Garfield wrote:
On Wednesday 05 December 2007, Stanislav Malyshev wrote:
implementation [details] not the concept. I believe that the
implementation needs a little ironing out ... what's the harm in taking
the time to do this? or at least taking the time to let consensus take
hold?
2007/12/5, Jochem Maas [EMAIL PROTECTED]:
metrics that support your argument that namespaces will make code more
maintainable, offer better structure and cleaner code.
Metrics aren't needed. I believe the almost 5 decades of OOP languages using
some sort of classes grouping and organization,
2007/12/5, Keryx Web [EMAIL PROTECTED]:
Stanislav Malyshev skrev:
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
What's 100% right? Any proposals (besides braces)?
Actually I did mention an alternative a while ago, and that would be to
learn
70 matches
Mail list logo
