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
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
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 r
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 na
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 M
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 i
+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
envi
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 ba
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
+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.
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
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
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
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 b
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
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 goin
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
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
Zend::Controller::Action::Plugi
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 hav
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 d
#1 and then #3.
Thanks :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 indifferent
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 you.
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 -
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 ha
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 unsubs
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 rea
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 Internal
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 p
Hi!
It does not allow calling both with the same import name, but it does allow:
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
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? Thr
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 m
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 warnings
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 to
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?
--
PHP Internals - P
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 separat
Hi!
Was your proposal to do this for name resolution:
Yes.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
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
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 d
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. F
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
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. It
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 mul
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 abso
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. So
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, o
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
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 a
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
+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 ar
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 politic
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 r
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
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
> namespac
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
> s
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
main.php
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, vi
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 hea
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 su
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 mix
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 su
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 m
erfect sense.
All that said, I want to personally thank-you 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
Sent: Wednesday, October 15, 2008 3:35
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 makes
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 tho
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?
Greg
--
66 matches
Mail list logo
