Hello Greg,
Many thanks for wirting a nice proposal. Now, I consider #2 and #4 as
no options, just as most everyone else. Regarding #3, I see it
contradicting our KISS approach. You can actually write code where an
Identifier in two scripts that share the same includes mean something
completely
+1 on #3 (I really was for option #2, but #3 seems to be more elegant).
As I remember this is a voting thread, but most of you started to argue
again and trashed the thread. Please stop doing that.
On Wednesday 15 October 2008 3:35:11 pm Greg Beaver wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
For the first point, #1 but with a less eyestrain-causing separator than :::.
Easy for both humans and compilers to tell the difference at any point
without referring back to the top of
Hi.
Sorry for yet another OT post in this thread.
Josh Davis wrote:
I have a question about 3. Where in a script can you use the use
statement? Could it be used inside conditionals? For example,
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
I hope this is a
+1 for #3 (use namespace or use class)
Regards,
Benjamin
On 15.10.2008, at 22:35, Greg Beaver wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
On Friday 17 October 2008 04:02:32 Gregory Beaver wrote:
Hi Stas,
This is not what is proposed. The E_WARNING is *only* on a name
conflict. Please re-read or try the patch:
http://pear.php.net/~greg/resolve_conflict.patch.txt
Greg
Any particular reason why it defaults to seeing it as a
Hi!
This is not what is proposed. The E_WARNING is *only* on a name
conflict. Please re-read or try the patch:
http://pear.php.net/~greg/resolve_conflict.patch.txt
I see the patch is doing zend_fetch_class, which autoloads. So
autoloading on each call to namespace function?
--
Stanislav
Regarding internal class resolving, it seems logical but will slow down
resolution within namespaces. But I doubt this is much of an issue as it
doesn't affect those not using namespaces.
I don't think that makes sense to say it doesn't affect people not using
namespaces when talking about
Stefan Walk wrote:
On Friday 17 October 2008 04:02:32 Gregory Beaver wrote:
Hi Stas,
This is not what is proposed. The E_WARNING is *only* on a name
conflict. Please re-read or try the patch:
http://pear.php.net/~greg/resolve_conflict.patch.txt
Greg
Any particular reason why it
Stanislav Malyshev wrote:
Hi!
This is not what is proposed. The E_WARNING is *only* on a name
conflict. Please re-read or try the patch:
http://pear.php.net/~greg/resolve_conflict.patch.txt
I see the patch is doing zend_fetch_class, which autoloads. So
autoloading on each call to
On Thu, Oct 16, 2008 at 12:35 AM, Greg Beaver [EMAIL PROTECTED] wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
solution #3: +1
change of resolving order: +1
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss.
Solution #1 is imho the best one to disambiguate everything, but the
readability problem is not to be overlooked. To keep this short, just
read the following rewrite of the lines for the problem code:
foo.php
?php
namespace
On Wed, 15 Oct 2008, Greg Beaver wrote:
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
Thank you, Greg, for your efforts.
My vote:
+1 for 3)
+1 for the change in __autolod()
On Wed, Oct 15, 2008 at 11:35 PM, Greg Beaver [EMAIL PROTECTED]wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are
Hello Greg,
Am Mittwoch, den 15.10.2008, 15:35 -0500 schrieb Greg Beaver:
[...]
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may
Greg Beaver schreef:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason
2008/10/15 Greg Beaver [EMAIL PROTECTED]:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
+1 for option 3, http://wiki.php.net/rfc/namespaceissues
Really don't want to see option 2.
Richard Quadling wrote:
2008/10/15 Greg Beaver [EMAIL PROTECTED]:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are
Greg Beaver wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove
If I understand correctly I vote.
+1 for Issue 1 option 1
+1 for Issue 2
On Wed, Oct 15, 2008 at 9:35 PM, Greg Beaver [EMAIL PROTECTED] wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and
Hi!
http://wiki.php.net/rfc/namespaceissues
My opinion for the proposals:
A. I'm ok with use namespace, but it is inferior to the - proposal.
While it allows explicit disambiguation, it does not allow to call both
in the same file. I'm not sure it's too much of a problem but
B. There's a
Hi Stas,
I think it would be better if we had limited number of variants. We have
many people here with all kinds of opinions, but the thing is we need to
choose ONE way and no more. So I'd propose to cut some options, otherwise
I suspect some people would be discouraged by too many options,
Hi!
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
I think it would be better if we had limited number of variants. We have
many people here with all kinds of opinions, but the thing is we need to
choose ONE way and no more.
On 16.10.2008, at 17:37, Stanislav Malyshev wrote:
B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad. It is not cacheable, it
leads to multiple disk accesses and it is
Lukas Kahwe Smith wrote:
On 16.10.2008, at 17:37, Stanislav Malyshev wrote:
B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad. It is not cacheable, it leads
to multiple disk
On 16.10.2008, at 18:59, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
On 16.10.2008, at 17:37, Stanislav Malyshev wrote:
B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad.
Hi!
first up i am a bit irritated by the use of the term internal class, i
guess you both mean to say class in the global namespaces?
I can't tell what Greg meant for him, but for me the problem exists
regardless of the class being internal or not.
imho the thing is, that the person who is
Lukas Kahwe Smith wrote:
On 16.10.2008, at 18:59, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
On 16.10.2008, at 17:37, Stanislav Malyshev wrote:
B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on
Stanislav Malyshev wrote:
Namespaces aren't autoloadable, classes are. But what I see happening
is that people would start converting excisting code, and since they
are human they will inevitable forget or miss class here and there.
And it would work, and pass all tests, and look fine and
great work - just one little note that may/may not help..
after much more thought I think you're option #2 is actually best
however the choice of ::: separator in the example really confuses
things and makes at an instant turn off..
I honestly think that if the option was rewritten as let's
Hi!
Was your proposal to do this for name resolution:
?php
namespace blah;
$a = new Exception;
1) if for blah::Exception exists, use it
2) try to autoload blah::Exception
3) fail
Yes.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829
after much more thought I think you're option #2 is actually best however
the choice of ::: separator in the example really confuses things and
makes at an instant turn off..
This concept was originally presented using the .. separator, and has been
presented with others since. The separator
Steph Fox wrote:
I think that pretty much disqualifies it as a solution for ns resolution
in PHP, sadly. If people on this list aren't able to fully grasp the
concept, it doesn't have a hope in user space.
agreed; one last little push can't hurt too much though can it?
(beats backtracking
I have been watching the namespace conversations for months and I can not
get my head around this fixation on a new separator. Other languages get by
without separate resolution syntax, why not solve these ambiguities through
rules of precedence like everyone else? Throw possible ambiguity
Stanislav Malyshev wrote:
Hi!
http://wiki.php.net/rfc/namespaceissues
My opinion for the proposals:
A. I'm ok with use namespace, but it is inferior to the - proposal.
While it allows explicit disambiguation, it does not allow to call
both in the same file. I'm not sure it's too much of a
Chris Stockton wrote:
I have been watching the namespace conversations for months and I can not
get my head around this fixation on a new separator. Other languages get by
without separate resolution syntax, why not solve these ambiguities through
rules of precedence like everyone else? Throw
Hi!
It does not allow calling both with the same import name, but it does allow:
?php
namespace blah;
include 'thing1.php';
include 'thing2.php';
use class ::foo;
use namespace ::foo as another;
foo::blah(); // static method
another::blah(); // namespace function
?
It's basically the same
I have a question about 3. Where in a script can you use the use
statement? Could it be used inside conditionals? For example,
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
If that's the case, could we have a word from an opcode cache guru
about how nice it would
Hi!
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
No, I don't think this would work since use is compile-time statement.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP
Greg Beaver wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to
Greg...
Hi Chris,
This is actually option #3 on the list of solutions at
http://wiki.php.net/rfc/namespaceissues
I know.
Steph: can you catalog this as a vote for it?
Not without Chris even looking at the options.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To
Hey Stas,
It's basically the same that my proposal does, only you have to work twice
as hard (two use's) and remember which name you assigned to what - and you
still would have to rewrite the code to use another:: - so you have to
both add use's _and_ rewrite the actual call code. And you'd
Stanislav Malyshev wrote:
Hi!
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
No, I don't think this would work since use is compile-time statement.
use is also a top_statement, which means it cannot be inside {} at all.
Greg
--
PHP Internals - PHP Runtime
Heya Scott,
I'd much rather see ::: used and don't care too much about those with
code already written, we never guarantee BC on unreleased versions.
Well, that narrows it down to #1 or #2.
Though I don't object to #3 at all either, so indifferent!
OK, so we have #1, #2 or #3 now from
On 17 Oct 2008, at 01:19, Steph Fox wrote:
Heya Scott,
I'd much rather see ::: used and don't care too much about those with
code already written, we never guarantee BC on unreleased versions.
Well, that narrows it down to #1 or #2.
Though I don't object to #3 at all either, so
#1 and then #3.
Thanks :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
Yes, but most times when there is conflict it will be between two sets
of code. So importing someone else's namespace explicitly and giving it
a new name is a good call IMHO.
If you have two distinct sets of code, why you use same namespace for
both of them? Namespaces are specifically
Hi Stas,
If you have two distinct sets of code, why you use same namespace for both
of them? Namespaces are specifically designed so you could have different
sets of code in different places.
I was unclear there, sorry. I was thinking of the situation where 'I use a
class that happens to
Hi!
I was unclear there, sorry. I was thinking of the situation where 'I use
a class that happens to have the same name as the namespace in a
third-party lib I need to use in my application'.
Why would you do that? I.e. suppose there's library having namespace
Steph Fox wrote:
#1 and then #3.
Thanks :)
- Steph
that is so wrong, you know 3 was better - you're not in my club :'(
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Why would you do that? I.e. suppose there's library having namespace
Zend::Controller::Action::Plugin - why would your name your class
Zend::Controller::Action::Plugin and not
Steph::Controller::Action::Plugin?
Why do you assume all third-party software is going to be ZF? Or that code
is
that is so wrong, you know 3 was better - you're not in my club :'(
Sorry to disappoint, but I'm collecting votes here, not making them up as I
go along.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox wrote:
that is so wrong, you know 3 was better - you're not in my club :'(
Sorry to disappoint, but I'm collecting votes here, not making them up
as I go along.
- Steph
twas directed at scott; an i typo'd n meant 3, and was misplaced humour
- tis 2am here and I really shouldn't
Hi!
Why do you assume all third-party software is going to be ZF? Or that
Are you familiar with the concept of example?
code is going to be written around third-party software in the first
place, rather than some useful lib that doesn't even exist yet might be
slotted into an app 3 or 10
Useful lib would have its own namespace and you would have your own.
The assumption to date has been that most userspace code wouldn't use
namespaces. Libraries and plugins would be more likely to use them. Ie the
chance of a ns/class collision isn't likely to be so much under the control
of
Stanislav Malyshev wrote:
Hi!
Yes, but most times when there is conflict it will be between two
sets of code. So importing someone else's namespace explicitly and
giving it a new name is a good call IMHO.
If you have two distinct sets of code, why you use same namespace for
both of them?
Hi,
I spent almost all day long reading your emails about ns
implementation (including one 100+ thread).
There are many useless discussions to be honest, some of them almost
going to personal side.
I think this should be a simple thread of voting, instead of start
another flame war here.
For
Hi
Like Guilherme wrote, I've spend alot of my day reading the emails and
trying to understand the namespace issues and after reading your
proposal I understand the issues you're bringing up. So heres my
votes:
Conflict between namespaced functions and static class methods:
I don't think it
Greg for getting us to focus on
the real issues, not the politics around it.
--Tony
- Original Message
From: Greg Beaver [EMAIL PROTECTED]
To: PHP Developers Mailing List internals@lists.php.net
Sent: Wednesday, October 15, 2008 3:35:11 PM
Subject: [PHP-DEV] my last attempt at sanity
Kalle Sommer Nielsen wrote:
Hi
Like Guilherme wrote, I've spend alot of my day reading the emails and
trying to understand the namespace issues and after reading your
proposal I understand the issues you're bringing up. So heres my
votes:
Conflict between namespaced functions and static class
Thank you for the voice of sanity, Greg. I agree with your approach.
-Andrei
Greg Beaver wrote:
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment
Hi,
Conflict between namespaced functions and static class methods:
I think that #4 solution is the best one. If it will be accepted, it would be
possible to extend namespaces in PHP6. For example, it would be possible to
allow mixing namespaces and classes with same names, and disallow only
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?
It
2008/10/15 Greg Beaver [EMAIL PROTECTED]:
Read it and discuss.
Hello,
First of all I'd like to thank Greg for his efforts to move the
discussion in a positive direction. From a PHP user's point of view,
it's comforting to see that this kind of discussion can still take
place with a cool head
64 matches
Mail list logo
