On Oct 17, 2008, at 3:53 AM, Nathan Rixham wrote:
*A Simpler Solution*
Force userland / general naming conventions in PHP.
# namespaces are always lowercase
# functions are always lowercase
# classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always the functi
I'm just a mere user, but if we go for other namespace separator (be it
::: or :> or anything else), then I'd rather see it used both between
namespace and class/function/constant name *and* between namespace parts.
OK, so maybe I should explain one little thing about the significance of
those
Paweł Stradomski wrote:
W liście Ryan Panning z dnia piątek 17 października 2008:
Request Autoload Gets Type
---
A::B:>C A::B:>C Class
A::B:>func() A::BNamespace
A::B:>C::CONST A::B:>C
W liście Ryan Panning z dnia piątek 17 października 2008:
> Request Autoload Gets Type
> ---
> A::B:>C A::B:>C Class
> A::B:>func() A::B Namespace
> A::B:>C::CONST A::B:>C Class
> A::B::
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
2008/10/17 Mike Willbanks <[EMAIL PROTECTED]>:
> 1. #3 - it is much cleaner to read than the other implementations in
> resolving the conflict. a different separator will be much harder to simply
> see from a comparison.
I beg to differ. A different separator (namespace scope resolution
operator)
OK, this is what we have. Please don't send any more votes on this now :)
NameIssue AIssue B
==
Greg#2 (alt #3, #1)Yes
Guilherme #3 Yes
Kalle
... and this poll is now closed. Thanks Aaron!
- Steph
- Original Message -
From: "Aaron Wormus" <[EMAIL PROTECTED]>
Newsgroups: php.internals
To: "Greg Beaver" <[EMAIL PROTECTED]>
Sent: Friday, October 17, 2008 6:12 PM
Subject: Re: my last attempt at sanity with namespaces
From the
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
1. #3 - it is much cleaner to read than the other implementations in
resolving the conflict. a different separator will be much harder to simply
see from a comparison. in a state where many people are in fact doing code
reviews and as it gets larger into big business the easier to read is going
t
Marcel Esser wrote:
> Using ::: as a namespace seperator would be great.
A general rule of telephony dialing and other data input, three of
the same character will too often be entered or recognized as two
or four characters due to user or mechanical error. That's why
when you see mnemonic phone
Hi Stas,
So far, my proposals hardly got any hearing at all, fair or otherwise -
they were totally ignored on the vote - never even mentioned except for
the note in Greg's wiki (which, despite being incorrect, was never fixed
or changed), and it looks like at least some of the persons were und
Hi!
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
So far, my proposals hardly got any hearing at all, fair or otherwise -
they were totally ignored on the vote - never even mentioned except fo
stef-com escribió:
> Hi
> My vote is option 1 please. "use ::: as separator between namespace name
> and element"
Ok, but please dont send your post with a "reading confirmation request"...
Thank you,
--
"A computer is like an Old Testament god, with a lot of rules and no
mercy. "
Cristian Ro
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
My vote is option 1 please.
"use ::: as separator between namespace name and element"
That's #2 :)
Please clarify. Also - please (briefly) explain why.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi
My vote is option 1 please.
"use ::: as separator between namespace name and element"
Thanks, bye
S.L.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Seems everyone is going for #3 ... I'm with the crowd. +1 on #3.
OK, this isn't a good reason. Please try to treat this poll with some
seriousness.
The voting patterns became skewed from here on, so the poll's still 5 votes
away from completion because I can't sanely use wildcard votes.
Wo
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
Issue A: #3
Issue B: +1 for Greg's suggestion
On Fri, Oct 17, 2008 at 8:06 AM, Mikael Forsberg <[EMAIL PROTECTED]> wrote:
> Another one.
>
> Issue A: #3
> Issue B: +1 for Greg's suggestion
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/uns
hi,
All references are now updated, in http://qa.php.net
http://bugs.php.net and http://snaps.php.net
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Seems everyone is going for #3 ... I'm with the crowd. +1 on #3.
> -Original Message-
> From: Steph Fox [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 17, 2008 6:40 PM
> To: Daniel Brown; Chris Stockton
> Cc: Lukas Kahwe Smith; [EMAIL PROTECTED]; internal
Hi Daniel,
There are about six total concurrent threads on this right now.
Would it make sense to create an OFFICIAL voting thread and *only*
count new votes posted to that thread from now until the fifty-vote
mark? Otherwise it seems that it introduces more confusion into an
already loaded iss
My vote is for option #3 and for Gregs proposal too.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
+1 #3
On Fri, Oct 17, 2008 at 9:35 AM, Ryan Panning <[EMAIL PROTECTED]> wrote:
> 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 poli
On Fri, Oct 17, 2008 at 11:08 AM, Chris Stockton
<[EMAIL PROTECTED]> wrote:
>> I'm going to stop this tally at 50 responses. That should be enough to show
>> us where people generally are coming from.
There are about six total concurrent threads on this right now.
Would it make sense to create
Another one.
Issue A: #3
Issue B: +1 for Greg's suggestion
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I would like to vote for #3.
On Fri, Oct 17, 2008 at 7:42 AM, Steph Fox <[EMAIL PROTECTED]> wrote:
> Hi Lukas,
>
> We are not ready yet. So for now I will not force a decision just yet.
>> Hopefully next week ...
>>
>
> I'm going to stop this tally at 50 responses. That should be enough to show
Another one who can't get through...
- Original Message -
From: "Ken Guest" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 17, 2008 3:37 PM
Subject: Fwd: namespaceissues
-- Forwarded message --
From: Ken Guest <[EMAIL PROTECTED]>
Date: Fri, Oct 17,
Yet another user, also with a reasonably significant project currently
using namespaces:
Issue A: #3
Issue B: +1 for Greg's suggestion
Again, just a user, please feel free to disregard.
- Nate
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/u
Hi Lukas,
We are not ready yet. So for now I will not force a decision just yet.
Hopefully next week ...
I'm going to stop this tally at 50 responses. That should be enough to show
us where people generally are coming from.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
T
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
Using ::: as a namespace seperator would be great.
---
Marcel Esser, Technical Lead
Croscon, LLC
http://www.croscon.com
---
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Issue A: #2, alternate #3, least #1
Issue B: Yes
--
CRB
+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
Pierre,
Is there something I need to do in snaps code?
BTW... if you want me to directly update source (and get it), I think
I'll need karma for that... I know I have for PHPWEB.
I'll be in São Paulo on CONISLI this weekend, but I can definately do
something beginning next week.
Cheers,
On Fri
Lukas Kahwe Smith wrote:
From now on I will simply stop to read any post from you as long as
there is uppercase words in it. It is annoying, respectless and does
not make your point any better.
I make no apologies for formatting text as I see fit. It would have
been very useful if you had sim
AFAIK the classes and the namespaces both are case insensitive. This means a
major change (to make them to be kept in a sensitive way) and will break the
code that depends on the insensibility.
IMHO - bad idea.
And besides the casing usially is used to enforce good coding practices, not
language fe
On Fri, 17 Oct 2008, Nathan Rixham wrote:
> thoughts, opinions, reasons why it wouldn't work?
Posts like this want me to shutdown this list, start a new one, hide it,
and make it invite only.
Derick
--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.o
Nathan Rixham wrote:
thus:
//this is always the function two in namespace one::step
one::step::two();
//this is always the method two of class step in namespace one
one::Step::two();
thoughts, opinions, reasons why it wouldn't work?
Though: this will break a awful lot of existing code
Opinion
On 17.10.2008, at 12:28, Lester Caine wrote:
Pierre Joye wrote:
From now on I will simply stop to read any post from you as long as
there is uppercase words in it. It is annoying, respectless and does
not make your point any better.
I make no apologies for formatting text as I see fit. It w
*The Problem (as defined by Greg):*
foo.php:
main.php:
*A Simpler Solution*
Force userland / general naming conventions in PHP.
# namespaces are always lowercase
# functions are always lowercase
# classes are always CamelCaps with initial uppercase letter enforced
thus:
//this is always th
Pierre Joye wrote:
From now on I will simply stop to read any post from you as long as
there is uppercase words in it. It is annoying, respectless and does
not make your point any better.
I make no apologies for formatting text as I see fit. It would have been very
useful if you had simply co
Hi Pierre
Thank you very much. I was looking for it in hhtp://snaps.php.net and it's
outdated - last 5.2.x in August, 06.
As many people only know snaps.php.net maybe you or someone with proper
rights could update it.
regards
holo
""Pierre Joye"" <[EMAIL PROTECTED]> escreveu na mensagem
news:
hi Lester,
On Fri, Oct 17, 2008 at 11:28 AM, Lester Caine <[EMAIL PROTECTED]> wrote:
> Pierre not sure when http://windows.php.net/snapshots/ appeared but who do
> we need to kick to perhaps get a link to it on http://snaps.php.net/ THAT is
> the site that is currently linked to everywhere when
Pierre Joye wrote:
hi,
On Fri, Oct 17, 2008 at 11:00 AM, Holografix <[EMAIL PROTECTED]> wrote:
Hi.
It's have been a week since 5.2.7RC1 and there is no Windows version yet.
Maybe someone could fix the snapshot buildings.
It is fixed since long and works (http://windows.php.net/snapshots/).
H
2008/10/17 Pierre Joye <[EMAIL PROTECTED]>:
> hi,
>
> On Fri, Oct 17, 2008 at 11:00 AM, Holografix <[EMAIL PROTECTED]> wrote:
>> Hi.
>> It's have been a week since 5.2.7RC1 and there is no Windows version yet.
>> Maybe someone could fix the snapshot buildings.
>
> It is fixed since long and works
hi,
On Fri, Oct 17, 2008 at 11:00 AM, Holografix <[EMAIL PROTECTED]> wrote:
> Hi.
> It's have been a week since 5.2.7RC1 and there is no Windows version yet.
> Maybe someone could fix the snapshot buildings.
It is fixed since long and works (http://windows.php.net/snapshots/).
However, this rele
Hi.
It's have been a week since 5.2.7RC1 and there is no Windows version yet.
Maybe someone could fix the snapshot buildings.
regards
holo
"Ilia Alshanetsky" <[EMAIL PROTECTED]> escreveu na mensagem
news:[EMAIL PROTECTED]
> The first release candidate of 5.2.7 was just released for testing and
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
52 matches
Mail list logo
