Greg Beaver wrote:
> Hi all,
>
> Let me make this brief: there will be lots of complaining about the
> namespace separator.
>
> Stop. Now.
And if you had the common decency not to change the thread-id and subject
some on this list might respect the spirit of your plea.
--
PHP Internals - PHP
On Mon, Oct 27, 2008 at 01:15, Greg Beaver <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Someone mentioned that it is possible to change keybindings so that it
> is easier to do [] {} and \. The only post I've found that mentions
> anything about this is
>
> http://chneukirchen.org/blog/archive/2007/12/wie
On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
2008/10/26 Johannes Schlüter <[EMAIL PROTECTED]>:
On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote:
So, I propose its either being a "supported" feature, or simply
put an
deprecation notice on it (5.3) and remove it HEAD. I p
On 24.10.2008, at 14:15, Felipe Pena wrote:
Hi youngs,
What about moving mSQL to pecl? :)
I guess thats a go then.
Derick you said you could handle the move?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
William A. Rowe, Jr. wrote:
> Greg Beaver wrote:
>> Hi all,
>>
>> Let me make this brief: there will be lots of complaining about the
>> namespace separator.
>>
>> Stop. Now.
>
> And if you had the common decency not to change the thread-id and subject
> some on this list might respect the spirit
2008/10/27 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
>
> On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
>
>> 2008/10/26 Johannes Schlüter <[EMAIL PROTECTED]>:
>>>
>>> On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote:
So, I propose its either being a "supported" feature, or
2008/10/27 Hannes Magnusson <[EMAIL PROTECTED]>:
> But now you suddenly want to tell people how to change their
> keybindings? Goto sleep man.
Wow, that's incredibly hostile, uncalled for and counter-productive.
You are attacking Greg for going out of his way to accomodate those
inconvenienced by
Now you can read the funny comments
http://developers.slashdot.org/developers/08/10/26/1610259.shtml
another thing about it is that if you search for namespace separator on google
it gives you php related discussions
so it must be something important
http://www.google.com/search?q=namespace sepa
On Mon, Oct 27, 2008 at 08:48, Josh Davis <[EMAIL PROTECTED]> wrote:
> 2008/10/27 Hannes Magnusson <[EMAIL PROTECTED]>:
>
>> But now you suddenly want to tell people how to change their
>> keybindings? Goto sleep man.
>
> Wow, that's incredibly hostile, uncalled for and counter-productive.
> You ar
Hi list,
to me it does not seem to make sense to use tabs or linefeeds (or
whatever other strange escaped characters) in namespace'd names. So I'd
suggest generating a fatal error when somebody uses them.
Regards,
Stefan
--
>e-novative> - We make IT work for you.
http://www.e-novative.de
e
Well, given how much PHP has copied from C (and I mean that in a good
way), why not copy the sane, less-controversial namespace separator
and behavior that we all know and love?
\Tudor
On Sun, Oct 26, 2008 at 4:23 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
> Tudor Prodan wrote:
>>
>> PHP has t
On Mon, Oct 27, 2008 at 12:33 PM, Tudor Prodan <[EMAIL PROTECTED]> wrote:
> Well, given how much PHP has copied from C (and I mean that in a good
> way), why not copy the sane, less-controversial namespace separator
> and behavior that we all know and love?
because C is static, and PHP is dynamic
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (67 total -- which includes 32 feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
===
I want to express my happiness of finally having an agreement/solution for
the namespaces.
I have something like 70 000 LOC with namespaces (and a lot of static
calls/class consts) so it will take some time to convert it to \ but I'm
still very happy to have a solution. Like Karsten Dambekalns sai
Lester Caine wrote:
The backslash is not ideal, but I think we all need to get behind it
rather than complaining. The only other real alternative today is to
shelve namespaces altogether for the next release rather than putting
something in that is simply not practical to extend later?
I'd pref
This was argued for months, there was tons of emails to read and backslash
is best for most people. PHP is dynamic language - that makes some major
restrictions, so you just can't apply something that is already in use
easily. That's why :: was rejected in first place. That's why . was
rejected, ot
So does that mean the new NS operator is actually \\ and not \ ?
No developer is going to be relying on single \'s -- too likely to become an
error in maintenence, and too inconsistent (see strings discussion).
Jevon
On Tue, Oct 28, 2008 at 12:11 AM, Arvids Godjuks
<[EMAIL PROTECTED]>wrote:
> T
Hi,
Now that we have a separator, it's time to clarify what happened to the
resolution order for functions and classes, which if I read Greg's messages, is
still not clearly defined.
1) I think we've established that autoloading + fallback for classes is
unworkable, as it either causes excess
On Tue, Sep 23, 2008 at 13:54, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
>
> I have not talked to Johannes about this, but unless there is a major major
> major outcry from the internals folks to add it, its too late for 5.3.
I count one "vote" against it...
-Hannes
--
PHP Internals - PHP Ru
I disagree that PHP being a dynamic language justifies the introduction
of deeply unpopular syntax. I mean, PHP developers are your end users.
Bad past design decisions aside, you don't want to alienate your users.
And yes, this has probably been argued in the past. Unfortunately, it
looks lik
On Mon, 27 Oct 2008, Thomas Lee wrote:
> I disagree that PHP being a dynamic language justifies the
> introduction of deeply unpopular syntax. I mean, PHP developers are
> your end users. Bad past design decisions aside, you don't want to
> alienate your users.
>
> And yes, this has probably b
Hi Thomas,
Anyway, my point is that there may be other options. Such as putting off a
long-sought feature until it can be implemented properly.
OK, since you obviously didn't do any background reading before posting to
this list, let me direct you to the history behind this decision once aga
I apologise for being silent on this issue to date (been busy), but I feel that
I must comment even if the decision is now 'final'.
On Mon, Oct 27, 2008 at 10:38:07PM +1100, Thomas Lee wrote:
> I disagree that PHP being a dynamic language justifies the introduction
> of deeply unpopular syntax. I
I agree with Thomas Lee, if the backslash ever gets released, it's
there forever.
Who uses functions and variables in a namespace anyway? very few
Will that small part of the users even use namespaces? probably not
So, why not ban these from namespaces and save all the trouble?
If however a user
Thanks for all your hard work guys. While \ separator is a bit weird,
I wholeheartedly support the decision to use a distinct separator for
namespaces.
On 25-Oct-08, at 2:07 PM, Lukas Kahwe Smith wrote:
Hi all,
Thx to the initiative of Scott and Steph we had an IRC discussion
with sever
On Mon, 2008-10-27 at 10:02 +0100, Stefan Priebsch wrote:
> Hi list,
>
> to me it does not seem to make sense to use tabs or linefeeds (or
> whatever other strange escaped characters) in namespace'd names. So I'd
> suggest generating a fatal error when somebody uses them.
\n is no newline (yes "\
2008/10/27 Ilia Alshanetsky <[EMAIL PROTECTED]>
> Thanks for all your hard work guys. While \ separator is a bit weird, I
> wholeheartedly support the decision to use a distinct separator for
> namespaces.
>
Totally agree, Originally I thought WTF they've chosen \ but once I got past
all the FUD
On Mon, 27 Oct 2008, Thomas Lee wrote:
How would delyaing it help?
I agree, delaying will not help (and namespaces are the most expected
feature in PHP 5.3).
If we could have made :: work, we would have. Greg (and others)
spend countless hours trying out different concepts, with different
1. One user of namespaced constants & functions here... I dont like to use
objects for everything. I have very few constants & functions but I would
like them to remain constants & functions instead of converting them to
static classes or object methods.
2. One reason against dropping ns for functi
William A. Rowe, Jr. wrote:
> Greg Beaver wrote:
>
>> Hi all,
>>
>> Let me make this brief: there will be lots of complaining about the
>> namespace separator.
>>
>> Stop. Now.
>>
>
> And if you had the common decency not to change the thread-id and subject
> some on this list might respec
Steph Fox wrote:
Hi Thomas,
Anyway, my point is that there may be other options. Such as putting
off a long-sought feature until it can be implemented properly.
OK, since you obviously didn't do any background reading before
posting to this list, let me direct you to the history behind this
David Grudl wrote:
But what is the purpose of namespaces? To give developers their own
separated space. And it is their responsibility to not use ambiguous
names. PHP has not problem with class Foo::Bar and namespace Foo::Bar,
but coding standards usually prohibits it.
+1 to that.
Cheers,
Hi Thomas,
Actually I've been following namespaces for a fair while, but the issue of
:: being a problem wasn't really raised until a few weeks ago. So while
I'm aware of namespaces being under discussion for a fair while, yesterday
was the first I'd heard about a decision being made for the b
At any rate I am very sure I never stumbled over code defining a
> constant with a ressource.
I did stumble over such thing ;)
Not a very good idea to support ressources,
> especially given the obvious WTF's this causes (as you rightly pointed
> out).
http://stuff.cristianrodriguez.net/patch
Lukas Kahwe Smith schrieb:
> Now the people that were not able to attend this IRC meeting can
> either accept that there was a sufficient number of people to make
> a final decision on something that everybody (obviously also people
> who did not attend the meeting) had plenty of time to make the
Greg Beaver schrieb:
> I stand by my obvious public intent with the multiple emails, RFCs and
> patches I have sent.
Just to make it clear: I appreciate your effort and work on namespaces,
but AFAICS there is no single/complete RFC, only bits and pieces
(problems with the current implementation
Greg Beaver schrieb:
>> It was mentioned on IRC that internal functions have to be
>> prefixed with \ when used in a namespaced file. Without a fallback.
>
> This is not true, and the unit tests demonstrate that
Thank you for clearing this up.
> 1) check for namespaced\functionname
> 2) check
On Mon, Oct 27, 2008 at 15:09, Sebastian Bergmann
<[EMAIL PROTECTED]> wrote:
> Lukas Kahwe Smith schrieb:
>> Now the people that were not able to attend this IRC meeting can
>> either accept that there was a sufficient number of people to make
>> a final decision on something that everybody (obviou
Actually I've been following namespaces for a fair while, but the
issue of :: being a problem wasn't really raised until a few weeks
ago.
I realize this isn't a terribly constructive comment as it doesn't
solve any problems, but I hope it's constructive in the way that it
actually causes
Hannes Magnusson schrieb:
> What exactly are you expecting other then the various wiki entries
> and README.namespaces in CVS?
Right, various sources of information that are not neccessarily in
sync and/or up to date.
--
Sebastian Bergmann http://sebastian-bergmann.de
I think the majority of the namespaces stuff is fine. However, having
read the irc discussion about how the namespaces seperator was decided
upon, i don't think there are many people here who can honestly say
that ease of typing is that big of a deal compared to maintainability
and being able to ea
While overall solid, I have 1 api critique that may or may not influence
inclusion..
The naming's seem slightly awkward for HttpResponse. Seemingly,
HttpResponse is the compliment to HttpRequest given their namings. But
looking at the api (the fact that its all static methods), it leads me
On Tue, 2008-10-28 at 01:43 +1030, Andrew Mason wrote:
> Both Perl and C++ use :: to success. i don't know how much of an
> overlap there is in PHP and Perl or C++ programmers, so I'm not
> suggesting it for familiarity reasons, but i have never heard anyone
> say "i wish C++/ Perl used a different
I found that he had one valid question that i would like to see answered.
> is the below allowed ?
>
> $bar = new Module \ Foo \ Bar();
>
> I find it easier to read than with out the space.
Since it looks pretty good with the spaces there.
2008/10/27 Johannes Schlüter <[EMAIL PROTECTED]>:
> On T
Hi!
If you read everything linked from that RFC, you will discover that
there are two ways to implement namespace support in PHP 'properly'.
1) We can offer support for classes only and throw a fatal error when a
function is encountered in namespaced code
2) We can use a namespace separator
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
That's the wrong way to do it - it means every time you mention the
internal class name without prefixing it with \ you get exhaustive
autoloading search and nothing tells you about
Stanislav Malyshev wrote:
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
That's the wrong way to do it - it means every time you mention the
internal class name without prefixing it with \ you get exhaustive
autoloading search a
These aren't the only ways.
OK.
4) Claim that there is no real problem in addressing ambiguous situations.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Oct 27, 2008 at 16:50, Ólafur Waage <[EMAIL PROTECTED]> wrote:
> I found that he had one valid question that i would like to see answered.
>
>> is the below allowed ?
>>
>> $bar = new Module \ Foo \ Bar();
>>
>> I find it easier to read than with out the space.
>
> Since it looks pretty goo
Hi!
OK.
4) Claim that there is no real problem in addressing ambiguous situations.
This is not what I meant, but there's obviously neither use nor interest
in further discussing this topic as decision was already taken. I only
wish people would not start rewriting history as other opinions
This is not what I meant, but there's obviously neither use nor interest
in further discussing this topic as decision was already taken. I only
wish people would not start rewriting history as other opinions or options
didn't even exist so soon. I'm fine with making the choice, what I'm not
fin
On Mon, 2008-10-27 at 17:53 +0100, Hannes Magnusson wrote:
> On Mon, Oct 27, 2008 at 16:50, Ólafur Waage <[EMAIL PROTECTED]> wrote:
> > I found that he had one valid question that i would like to see answered.
> >
> >> is the below allowed ?
> >>
> >> $bar = new Module \ Foo \ Bar();
> >>
> >> I fi
2008/10/27 Rodrigo Saboya <[EMAIL PROTECTED]>:
> I agree with Stas. It's better to force people to actually reference their
> classes/functions/constants correctly and get better performance than
> getting unclear slowdowns.
If I'm not mistaken, you only experience any noticeable slowdown if
all o
Hi!
- you use an internal class many, many times (as the overhead from a
handful of invocations would be negligible)
Actually, one time is enough, as it can bring an application from
essentially zero disk accesses (with bytecode caching) to multiple disk
accesses (to traverse full include pa
It doesn't take a lot to kill an application if using internal class causes
__autoload to run for a non-existing user class.
Neither caches not optimizations can avoid that, as you can't have something
cached which doesn't exist.
In my autoloader for example, an existing user class is resolve
> $class = '\ foo \ bar \ baz';
In those cases i get why its an issue. But when i look at:
namespace\class\method()
against
namespace \ class \ method()
I get the feeling that \ is a pretty good solution.
2008/10/27 Johannes Schlüter <[EMAIL PROTECTED]>:
> On Mon, 2008-10-27 at 17:53 +0100, Han
Johannes Schlüter wrote:
btw. this also affects quite a few other functions: next/current/key/...
at least ... and maybe more after using the "new" parameter parsing API.
I would say "no" for 5.3. But for 6 it would be fantastic to have all array-related
operations supporting ArrayAccess inter
btw. this also affects quite a few other functions: next/current/
key/...
at least ... and maybe more after using the "new" parameter parsing
API.
I would say "no" for 5.3. But for 6 it would be fantastic to have
all array-related operations supporting ArrayAccess interface, where
possible
Sean Coates wrote:
I was hoping someone would revive this thread (-:
In Habari, we have/had an ArrayObject that we passed to the view
(theme). As far as the theme knows, this is an array (but it has extra
methods if the theme is particularly smart).
Unfortunately, this breaks in 5.3, because
You're welcome.
Benjamin Schulz wrote:
Thanks for another great argument to move away from PHP asap.
On 25.10.2008, at 20:07, Lukas Kahwe Smith wrote:
that we have decided to go with backslash as new separator for
namespaces.
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
On Mon, 2008-09-22 at 20:17 +0200, Michael Wallner wrote:
> I wonder what the general opinion is on adding pecl/http to the main PHP
> distribution? Many people have poked me in the past, so I guessed it's
> time to ask me and you that question once for all.
I didn't took a deeper look at it yet,
Vesselin Kenashkov wrote:
1. One user of namespaced constants & functions here... I dont like to use
objects for everything. I have very few constants & functions but I would
like them to remain constants & functions instead of converting them to
static classes or object methods.
2. One reason ag
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
> Actually, one time is enough, as it can bring an application from
> essentially zero disk accesses (with bytecode caching) to multiple disk
> accesses (to traverse full include path to exhaust all autoloading
> capabilities).
So we're talking a
Hi!
Then, if we assume that most people will use the global namespace
without prefixing it, what would be the best resolution order for
them? (you didn't mention it in your previous message)
Using the prefixed names.
People who care about performance are supposed to profile their
code... I g
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
>> Then, if we assume that most people will use the global namespace
>> without prefixing it, what would be the best resolution order for
>> them? (you didn't mention it in your previous message)
>
> Using the prefixed names.
I'm sorry but I stil
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
How would you reorder those?
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) fail
...but didn't you say "one time is enough"? According to your own
log
2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
> 1) check for namespaced\classname
> 2) try to autoload namespaced\classname
> 3) fail
Ok, that makes some sense wrt your position, which I originally
interpreted as namespace/internal/autoload.
You want to force users to use the full name at a
You want to force users to use the full name at all times. IOW, you
want to sacrifice convenience for performance.
(chiming in because it seems that we're overlooking something obvious
here)
If it comes down to this, I'd prefer to see an E_NOTICE for the "bad
performance" use, though I do
On 27.10.2008, at 22:27, Sean Coates wrote:
You want to force users to use the full name at all times. IOW, you
want to sacrifice convenience for performance.
(chiming in because it seems that we're overlooking something
obvious here)
If it comes down to this, I'd prefer to see an E_NOTI
Hi!
this seems like a very good idea to me. this way things default to "just
work" (which imho is the PHP spirit), while its brain dead easy to
detect misuse.
They not "just work" - they "work" in a wrong way (not usable in any
practical application). And E_NOTICE is a non-solution here - i
On 27.10.2008, at 23:01, Stanislav Malyshev wrote:
Hi!
this seems like a very good idea to me. this way things default to
"just work" (which imho is the PHP spirit), while its brain dead
easy to detect misuse.
They not "just work" - they "work" in a wrong way (not usable in any
practic
Hi!
just the same reason as you can use a constant without initialization.
out of the box PHP does not try to be a teacher. it lets you write you
Constant without initialization doesn't lead to any problems. This one
does.
this is how PHP got its huge userbase. we let people grow with the
On 27.10.2008, at 23:27, Stanislav Malyshev wrote:
this is how PHP got its huge userbase. we let people grow with
their needs.
And how exactly it serves the needs of people by secretly making
their applications orders of magnitude slower, and then saying "oh,
that's because you failed to
Josh Davis wrote:
> 2008/10/27 Stanislav Malyshev <[EMAIL PROTECTED]>:
>
>> 1) check for namespaced\classname
>> 2) try to autoload namespaced\classname
>> 3) fail
>
> Ok, that makes some sense wrt your position, which I originally
> interpreted as namespace/internal/autoload.
>
> You want to fo
Johannes Schlüter escribió:
>or http.only_exceptions should
> imo be set as object properties (or similar), not globally using ini
> settings.
Or just throw only exceptions and no ini setting at all.
--
"A computer is like an Old Testament god, with a lot of rules and no
mercy. "
Cristian Rod
Hi Stas, and All,
I understand that there is a strong desire for this thread to be dead.
However, after reading this and all related threads and wiki, I find that
one item is still unclear, at least to me.
On Mon, Oct 27, 2008 at 6:27 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
> And how
Hey,
I think that using \ to prefix global symbols in namespaces would be
quite dumb. It would feel counter-intuitive because then if your
coding you would need to think to yourself, "am I in a namespace?",
thus increasing the chance for simple errors. It would be incedibly
annoying when writing p
77 matches
Mail list logo
