+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 17.10.2008, at 04:18, Steph Fox wrote:
just wondering if there are any cut of dates for the tally dates /
rounds etc?
When this tally started out, I'd been told that there had to be a
cut-and-dried answer by tonight or forget it.
We are not ready yet. So for now I will not force a dec
I am a "mere user" you can consider as well. I usually just read
internals. I wanted to add input into the namespace issue.
Using a difference of ::: or :: for separators is really confusing. I
could slip up in programing by missing a single : and then have to go
back to debug and it would
A "mere user" here too with some php namespace experience (with current
implementation).
Issue 1: Choice #4, with a fallback on choice #3
Issue 2: This should be a php.ini option, typically it's going to cause
a lot of (useless) calls to __autoload() for some existing code while
migrating to a na
On Thu, Oct 16, 2008 at 3:33 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> I was hoping to have at least 30 respondees at this stage, but actually have
> 29 (and that includes Hannes' abstention). However, to keep y'all up to
> date, here's where we're up to with Greg's proposals.
Sorry for comi
I'm another "mere user", but here are my votes
Issue 1: Choice #3
Issue 2: Agree with Greg.
Josh Heidenreich
ZCE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm just a "mere user" but here's how I would vote:
Issue 1: Choice #4 (with an alternate choice for #3). My eye sight is bad
enough without having to distinguish between :: and :::.
Issue 2: Vote yes for Greg. It just makes sense to me.
-Tim
Timothy Boronczyk, ZCE
[EMAIL PROTECTED]
just wondering if there are any cut of dates for the tally dates / rounds
etc?
When this tally started out, I'd been told that there had to be a
cut-and-dried answer by tonight or forget it. Then it was pointed out to me
that Stas' proposal wasn't getting a fair hearing. Then it turned out tha
Steph Fox wrote:
I was hoping to have at least 30 respondees at this stage, but actually
have 29 (and that includes Hannes' abstention). However, to keep y'all
up to date, here's where we're up to with Greg's proposals.
Option #3 is in the lead, but that lead is still pretty fragile; there
ar
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
Hi Michael,
Forwarding to internals@ and counting you in.
I tried to mail the list, but it never seemed to go through.
I'm just a user, but a serious one, with frameworks to maintain.
I've already done a branch of an app framework to the current
namespaces implementation comfortably.
FWIW,
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
Hi!
The proposal does not solve the name conflict. If no one rewrites their
Right, it does not. So doesn't yours - you need to modify the code in
both cases.
the solution I proposed emits an E_WARNING on the conflict.
You proposed a number of solutions, apparently. That's why I asked to
Stanislav Malyshev wrote:
> Hi!
>
>> My point is that for this code:
>>
>> > Classname::Method();
>> ?>
>>
>> The proposal does not solve the name conflict. If no one rewrites their
>
> Right, it does not. So doesn't yours - you need to modify the code in
> both cases.
the solution I proposed emit
I was hoping to have at least 30 respondees at this stage, but actually have
29 (and that includes Hannes' abstention). However, to keep y'all up to
date, here's where we're up to with Greg's proposals.
Option #3 is in the lead, but that lead is still pretty fragile; there are
only 3 full vote
Hi!
hmm .. i also emailed Timm a few weeks ago and got no reaction. the
question now is .. does someone else care enough to work through the
issues Stas has noted to get things in shape to be committed?
Well, this thing is trickier that it appears initially. It can be done,
of course, but it
Hi,
So I guess the conclusion is:
Create a feature request ticket, take the information from this thread
and put it into the ticket .. and ideally write a patch yourself or
motivate someone else ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
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
2008/10/16 Steph Fox <[EMAIL PROTECTED]>:
> Please can those people who didn't already express a clear and relevant
> opinion, express it now? We don't have long to play with this if there's to
> be namespace support in 5.3.
Hi,
As far as I'm concerned, my preference goes to:
2. use a different
On 07.10.2008, at 21:59, Nathan Nobbe wrote:
hi all,
we are encountering an error in our code due to type hint
semantics. php is
allowing NULL values through a type hint for a class, however, if i
read the
manual, NULL, should only be allowed, if and only if, null is given
as the
defau
On 10.10.2008, at 22:58, Stanislav Malyshev wrote:
Hi!
I've updated the patch and added some tests with it.
http://sitten-polizei.de/php/getstatic.diff
Looked at the patch. There's some things I noticed there:
1. _getstatic->common.fn_flags |= ~ZEND_ACC_ALLOW_STATIC;
What was the idea here
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
Edmund Tam wrote:
(one::step)::two();
Yes, parenthesis, just like when we want to write (1 + 2) * 3.
So my question is: can parenthesis play a part in namespace resolving?
see this is the problem and where the solution should be (imo)
mynamespace::anotherspace::somespace
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
Hi!
My point is that for this code:
The proposal does not solve the name conflict. If no one rewrites their
Right, it does not. So doesn't yours - you need to modify the code in
both cases.
code to use Classname->Method(), then no one will be protected from the
ambiguity. I am thinkin
Hello all,
Sorry to post here being an "outsider".
I didn't post because I know nothing about the internals, really.
However after some incomplete thought I have a not very thorough
suggestion about the ambiguity issue mentioned in the RFC wiki.
I would like to ask if this is possible.
Let me quo
Since this got cut without am answer I'll repeat it since *I* would still like
to know the answer!
Lester Caine wrote:
So 'USE' ?
I'm I understanding things right on this one that one would 'define' the
namespace in one sort of header file, and then add the use namespace to
those files that b
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
Stanislav Malyshev wrote:
> Hi!
>
>> The problem with that statement is that if it is used to ignore the
>> other problems, then at some point it may be necessary to re-write all
>> the new namespace code simply to allow additional features to be added!
>
> So? We rewrote pretty much every other
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
i guess i should note that Steph's tally only includes votes on Greg's
proposal. Stas proposal is obviously also still up for vote.
Yes, we're going to have to go head-to-head at some stage very soon. Getting
it down from 5 proposals to 2 would make that a bit more possible though.
In that s
On 16.10.2008, at 16:14, Steph Fox wrote:
Please can those people who didn't already express a clear and
relevant
opinion, express it now? We don't have long to play with this if
there's to
be namespace support in 5.3.
At present it looks like a two-horse race between #1 full
disambiguat
On 16 October 2008, at 16:14:34, Steph Fox wrote:
> Janusz Lewandowski #4 Yes
My alternative choice for A is #3.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
On 16 Oct 2008, at 16:14, Steph Fox wrote:
Please can those people who didn't already express a clear and
relevant
opinion, express it now?
Issue A: #1.
Issue B: Yes.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
+1 and of course make the resolution as greg mentioned on the rfc in the
resolving access part (actually that was in stas's original original
post and I didn't realize we were still arguing over it ;)
NO, it wasn't in my proposal - my proposal was entirely different. My
proposal does not
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
In my opinion namespaces should be in 6 not 5.3 but ignoring that:
+1 for Issue 1 option 1
+1 for Issue 2
2008/10/16 Nathan Rixham <[EMAIL PROTECTED]>
> Steph Fox wrote:
>
>> Please can those people who didn't already express a clear and relevant
>> opinion, express it now? We don't have long to
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
Hi!
The problem with that statement is that if it is used to ignore the
other problems, then at some point it may be necessary to re-write all
the new namespace code simply to allow additional features to be added!
So? We rewrote pretty much every other part of PHP - engine, object
model, fi
On 10/15/08 4:35 PM, 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
stupid-ass r
Hi!
Gregory Beaver wrote:
Hi again,
I was asked to explain why I hadn't included ClassName->Method(); in the
list of ideas that solve the ambiguity problem. I added a brief section
to the RFC that does so:
http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work
Wha
Steph Fox wrote:
Please can those people who didn't already express a clear and relevant
opinion, express it now? We don't have long to play with this if there's to
be namespace support in 5.3.
At present it looks like a two-horse race between #1 full disambiguation
(:::) and #3 explicit disambi
+1 for option 3 too (http://wiki.php.net/rfc/namespaceissues)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Please can those people who didn't already express a clear and relevant
opinion, express it now? We don't have long to play with this if there's to
be namespace support in 5.3.
At present it looks like a two-horse race between #1 full disambiguation
(:::) and #3 explicit disambiguation ('use name
+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
The thread where your vote has to go is:
[PHP-DEV] my last attempt at sanity with namespaces
started also by Gregory.
On Thu, Oct 16, 2008 at 5:30 PM, Justin Carlson <[EMAIL PROTECTED]>wrote:
>
> I vote for option 3.
>
> http://wiki.php.net/rfc/namespaceissues
>
> Seems like the best fit all arou
I vote for option 3.
http://wiki.php.net/rfc/namespaceissues
Seems like the best fit all around.
Steph Fox wrote:
Hannes, Lester...
Can we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.
The problem with that statement is
Hannes, Lester...
Can we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.
The problem with that statement is that if it is used to ignore the other
problems, then at some point it may be necessary to re-write all the new
namespace
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
Hi!
What would happen if we give the namespace implementation a chance to
mature is that it can be delivered as a fully-fledged language element
rather than a partially-fledged and potentially flawed one.
What do you mean by "chance to mature"? Only chance for it to mature is
people actually
Hi Greg, everyone.
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
stupid-ass re
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 08:54, Lester Caine <[EMAIL PROTECTED]> wrote:
> Hannes Magnusson wrote:
>>>
>>> I was asked to explain why I hadn't included ClassName->Method(); in the
>>> list of ideas that solve the ambiguity problem. I added a brief section
>>
>> Can we please start small and then inc
87 matches
Mail list logo
