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 German keyboards,
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
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 classes
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 day* to
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
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 that
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
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,
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+?,
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
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 german
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 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 ?
Ólafur
Ó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 something in
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
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
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
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
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
to
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 if
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
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 characters due
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:
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:
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:
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-DEV] Namespace issues
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:
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
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
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
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
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
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) namespace
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
fundamentally
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
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]
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 using
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 the
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
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 require
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 namespaces
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. Simplify
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 the
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
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
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
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
47 matches
Mail list logo
