Steph Fox wrote:
Have we reached a consensus? Or is this still a little open ended?
Scott's trying to pull together a developer-only meeting so we can look
at what's left in a bit more depth. Once we've done this it'll probably
come back to the list (should, IMHO).
Timezones, timezones!
Steph Fox wrote:
What we're hearing here about European keyboard layouts is useful info
because it gives some idea of how popular/unpopular the backslash would
be as a solution and why, but it shouldn't carry as much weight as the
accessibility argument against the triple colon. One is liveable
>
> Clarity and simplicity are the two chief requisites. We're all fully
> aware
> of that, from Engine developer to n00b, so there's really no point in
> discussing it to death on-list at this stage.
>
Yep. I agree. I'm already tired of watching this thread. Let them agree
on an implementation
Hi,
Guys, this is like junior school in here.
Yep.
Let me put some things in perspective:
No, let me. Greg worked his butt off the entire weekend looking for the
flaws in *all* the options available to us, including a couple of new ones
that never even reached the list before he rejected
2008/10/21 Stan Vassilev | FM <[EMAIL PROTECTED]>
>
> Hi,
>
> Guys, this is like junior school in here.
>
> Let me put some things in perspective:
>
> 1) The location of backslash on foreign keyboard is entirely irrelevant for
> the choice of namespace separator. Why? You already use this *every d
The N word discussion looks neverending...
solution #3 from Gregory solves the ambiguity so I dont see how it will
"create such nightmares in big projects with ambigous identifiers". I'm
using the :: operator for the last 6 months and I had no such issues even
without the fix (I'm not naming classe
Hi,
Guys, this is like junior school in here.
Let me put some things in perspective:
1) The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this *every day* to
escape characters in your strings and regular expressio
On Mon, 20 Oct 2008, Philipp Wagner wrote:
> Steph Fox wrote:
> > Hi Lester,
> >
> >> And there are no problems with those on foreign keyboards?
> >
> > If there are, those foreign keyboards are unable to offer either escaped
> > chars or MS paths... which seems highly unlikely.
>
> Well, on Ge
Ilia Alshanetsky wrote:
Another issue I just came across caused by :: being used for both
namespaces and classes is the fact when it comes to validation such as
the one I've just put it for constant names, its impossible to determine
if the prefix is a namespace or a class name. So, I definitel
Another issue I just came across caused by :: being used for both
namespaces and classes is the fact when it comes to validation such as
the one I've just put it for constant names, its impossible to
determine if the prefix is a namespace or a class name. So, I
definitely think we should ch
I wasn't planning to open the ns separator discussion again. In fact I think
we'd all much rather avoid it completely...
As info, in a Spanish keyboard it's the same, Alt Gr+{the key to the left
of the 1}.
... but thanks for that part of your input (and same to Ólafur).
- Steph
--
PHP Inte
Ólafur Waage wrote:
On an icelandic keyboard "\" is AltGr + (key right of 0 in the top
row), just an fyi if you guys wanted to know.
For my two cents. "\" looks like its not supposed to be there.
Is there no other combination of two simbols that would work? Like >>
or +> or ** or .. or somethin
On an icelandic keyboard "\" is AltGr + (key right of 0 in the top
row), just an fyi if you guys wanted to know.
For my two cents. "\" looks like its not supposed to be there.
Is there no other combination of two simbols that would work? Like >>
or +> or ** or .. or something in that fashion ?
Ó
The "german keyboard" issue isn't really one. {}[] are in the same "class"
of
characters (alt-Gr + number-row). So, as a programmer, you either have to
live with that anyway because there's no avoiding {}[], or you switch to
the
us layout while programming (which quite a few people do).
Also
On Monday 20 October 2008 20:42:36 Steph Fox wrote:
> > Well, on German keyboards, it's accessible but only by using ALTGR+?,
> > which is not really a comfortable combination.
>
> Useful to know, thanks Philipp.
>
> Any more localized keyboard issues we should know about? Anyone?
>
> - Steph
The
Well, on German keyboards, it's accessible but only by using ALTGR+?,
which is not really a comfortable combination.
Useful to know, thanks Philipp.
Any more localized keyboard issues we should know about? Anyone?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi,
Steph Fox wrote:
> Hi Lester,
>
>> And there are no problems with those on foreign keyboards?
>
> If there are, those foreign keyboards are unable to offer either escaped
> chars or MS paths... which seems highly unlikely.
Well, on German keyboards, it's accessible but only by using ALTGR+?
Hi Lester,
And there are no problems with those on foreign keyboards?
If there are, those foreign keyboards are unable to offer either escaped
chars or MS paths... which seems highly unlikely.
But do I still understand that there is an alternative method that was not
part of this last roun
Hello David,
Sunday, October 19, 2008, 1:02:21 PM, you wrote:
>>> shift+;(x3) vs \
>>
> Ok I'll try to make a very neutral comment. For the moment most are
> still using an english keyboard (no matter which english in this case
> and I'd actually be interested in knowing numbers for a fact
>>>
>> shift+;(x3) vs \
>
Ok I'll try to make a very neutral comment. For the moment most are
still using an english keyboard (no matter which english in this case
and I'd actually be interested in knowing numbers for a fact if
anyone's got something) and ergonomically speaking, ::: is much easier
Nathan Rixham wrote:
Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '\' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:
shift+;(x3) vs
Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '\' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:
http://php.net/~helly/triplecolon.html
Quicker shift + ; x 3 than finding that freakin backslash on my HP 530 notebook.
> -Original Message-
> From: Nathan Rixham [mailto:[EMAIL PROTECTED]
> Sent: Sunday, October 19, 2008 2:52 AM
> To: internals@lists.php.net
> Subject: Re: [PHP
Marcus Boerger wrote:
Hello all,
Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '\' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:
htt
Marcus Boerger wrote:
Hello all,
Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '\' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:
htt
Hello all,
Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '\' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:
http://php.net/~helly/tripl
Hello William,
Friday, October 17, 2008, 7:57:53 PM, you wrote:
> 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 character
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
Vesselin Kenashkov wrote:
> I'm -1 for "removing constants and functions from the namespaces". As I
> wrote already in another thread, is it possible to have a fatal error thrown
> when the engine detects an ambiguity situation? Are there any logical (i
> mean from OOP point of view) or internals (
I'm -1 for "removing constants and functions from the namespaces". As I
wrote already in another thread, is it possible to have a fatal error thrown
when the engine detects an ambiguity situation? Are there any logical (i
mean from OOP point of view) or internals (performance and so on) problems
wi
On Tue, Sep 23, 2008 at 11:47:30AM +0400, Dmitry Stogov wrote:
> Stanislav Malyshev wrote:
> >
> > 3. Functions will not be allowed inside namespaces. We arrived to
> > conclusion that they are much more trouble than they're worth, and
> > summarily we would be better off without them. Most of the
Hi,
On Mon, 2008-09-22 at 12:45 -0700, Stanislav Malyshev wrote:
> 1. Allow braces for namespaces. So, the syntax for namespaces will be:
> a) namespace foo;
> should be first (non-comment) statement in the file, namespace extends
> to the end of the file or next namespace declaration.
> b) names
Arvids Godjuks wrote:
2008/9/22 Stanislav Malyshev <[EMAIL PROTECTED]>
Hi!
3. Functions will not be allowed inside namespaces. We arrived to
conclusion that they are much more trouble than they're worth, and summarily
we would be better off without them. Most of the functionality could be
easi
2008/9/22 Stanislav Malyshev <[EMAIL PROTECTED]>
> Hi!
>
> 3. Functions will not be allowed inside namespaces. We arrived to
> conclusion that they are much more trouble than they're worth, and summarily
> we would be better off without them. Most of the functionality could be
> easily achieved us
On Thursday 25 September 2008 9:08:27 am Lukas Kahwe Smith wrote:
> > No, namespaces for functions can most certainly *not* be emulated
> > with either
> > variable functions or static methods. Dropping namespace support for
> > functions makes namespaces mostly useless for anyone who is not 100%
Hi!
Right, Stas, did you also discuss removal of constants? Seems logical as
the really the same arguments apply.
IMO constants do not produce that much trouble, since they are not as
extensively used than methods and functions.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
On 23.09.2008, at 09:47, Dmitry Stogov wrote:
Stanislav Malyshev wrote:
Hi!
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk
about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:
1. Allow braces for
On 23.09.2008, at 05:39, Larry Garfield wrote:
"Most of the functionality could be easily achieved using static class
methods".
As someone who uses both functions and classes with equal comfort, I
have to
say "GAH, NO NO NO!" to that statement. Classes as pseudo-
namespaces are
fundamental
Hi,
1. and 2. are great. I'm happy to see this done.
But for 3. I think that's throwing the baby with the bathwater.
Since now global classes inside namespaces will need the "use ::Foo;" or
"::Foo...", I hope you can give a fresh look at my original idea that both
functions and classes requi
Am 22.09.2008 um 21:45 schrieb Stanislav Malyshev:
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk
about what we'd like to do with namespaces, and we arrived at the
following conclusions, which we propose to implement in 5.3:
1. Allow braces for namespaces. So, the syntax
Sounds fantastic to me.
Not a fan of the {} namespaces but each to their own.
On Tue, Sep 23, 2008 at 5:15 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
> On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
> what we'd like to do with namespaces, and we arrived at
Hi!
To clarify, with syntax B you can do multiple namespaces in one file? I have
no objection then.
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 u
Hi Stas,
Am Montag, den 22.09.2008, 12:45 -0700 schrieb Stanislav Malyshev:
[...]
> On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
> what we'd like to do with namespaces, and we arrived at the following
> conclusions, which we propose to implement in 5.3:
Thanks for th
On Mon, 22 Sep 2008, Stanislav Malyshev wrote:
> On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk
> about what we'd like to do with namespaces, and we arrived at the
> following conclusions, which we propose to implement in 5.3:
>
> 1. Allow braces for namespaces.
> 2. Simpli
Stanislav Malyshev wrote:
> Hi!
>
> On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
> what we'd like to do with namespaces, and we arrived at the following
> conclusions, which we propose to implement in 5.3:
>
> 1. Allow braces for namespaces. So, the syntax for namespac
Stanislav Malyshev wrote:
Hi!
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:
.
3. Functions will not be allowed inside namespaces. We arrived
On Monday 22 September 2008 2:45:51 pm Stanislav Malyshev wrote:
> Hi!
>
> On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
> what we'd like to do with namespaces, and we arrived at the following
> conclusions, which we propose to implement in 5.3:
>
> 1. Allow braces for na
Stanislav Malyshev schreef:
Hi!
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:
1. Allow braces for namespaces. So, the syntax for namespaces will
48 matches
Mail list logo