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
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 organiza
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?
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
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 c
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.
>
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 tha
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 fi
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 feat
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 t
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 I
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
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
>>
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 ide
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 updated
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 "t
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 supp
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 p
> > 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, th
-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 th
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 capa
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 s
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
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
+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 nice
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
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 unex
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:
var =
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 Mail
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 wi
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
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 res
+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 (m
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) names
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 worrie
+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 o
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:
var =
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
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
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 PROT
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 n
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
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
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 th
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 und
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 coatin
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):
A search & replace of "Default" would replace both,
T3::MyPackage::Contro
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
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
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
>> foll
> 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 res
> 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 ext
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 b
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 w
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 zen
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
Rasmus Lerdorf skrev:
It may not be the browser that misses the
Keryx Web wrote:
> Alexey Zakhlestin skrev:
>> I think I understand what the use-case is…
>>
>> If the browser doesn't know anything about 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
>>
>
>
Alexey Zakhlestin skrev:
I think I understand what the use-case is…
If the browser doesn't know anything about
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 ag
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_*,
Zend_
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
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 c
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 on
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 k
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 l
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 marker
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:
loadXML
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 mail
71 matches
Mail list logo
