2020-09-22 14:51 GMT, guilhermebla...@gmail.com :
> This should answer your question:
> https://github.com/php/php-src/pull/947#issuecomment-224912697
>
Yes, indeed. "The reason comes due to how namespaces are implemented
in the language, where they only exist at compile time." Pity.
> On Tue,
This should answer your question:
https://github.com/php/php-src/pull/947#issuecomment-224912697
On Tue, Sep 22, 2020 at 7:38 AM Olle Härstedt wrote:
>
> 2020-09-21 21:50 GMT, Rowan Tommins :
> > On 21/09/2020 17:13, Michael Morris wrote:
> >> Next thing to consider - we have the problem of
2020-09-21 21:50 GMT, Rowan Tommins :
> On 21/09/2020 17:13, Michael Morris wrote:
>> Next thing to consider - we have the problem of having already used the
>> protected keyword in PHP, and honestly I prefer PHP's interpretation of
>> the
>> word.
>
>
> I think it's actually Java that's the
On 21/09/2020 17:13, Michael Morris wrote:
Next thing to consider - we have the problem of having already used the
protected keyword in PHP, and honestly I prefer PHP's interpretation of the
word.
I think it's actually Java that's the outlier here: PHP's meaning of
"protected" corresponds
2020-09-21 16:13 GMT, Michael Morris :
> This sort of thing would be useful. Drupal and Symfony both mark methods in
> their libraries that aren't supposed to be used externally, but people do
> anyway and then they get mad at the framework developers when they decide
> to rearrange what are
This sort of thing would be useful. Drupal and Symfony both mark methods in
their libraries that aren't supposed to be used externally, but people do
anyway and then they get mad at the framework developers when they decide
to rearrange what are supposed to be internal methods.
I wrote a userland
On 17/09/2020 13:28, Olle Härstedt wrote:
We have public, protected and private. Since PHP has no module system, we
have no qualifier to mark a class property as "private for this module".
One solution to this could be to add a new qualifier "internal", to make
properties public within the
On Sat, 19 Sep 2020, 09:20 Olle Härstedt, wrote:
>
> On Fri, 18 Sep 2020, 00:13 Mike Schinkel, wrote:
>
>>
>>
>> > On Sep 17, 2020, at 8:28 AM, Olle Härstedt
>> wrote:
>> >
>> > (NB: This idea is NOT about namespace visibility for classes,
>> interfaces or
>> > traits (already discussed here:
On Fri, 18 Sep 2020, 00:13 Mike Schinkel, wrote:
>
>
> > On Sep 17, 2020, at 8:28 AM, Olle Härstedt
> wrote:
> >
> > (NB: This idea is NOT about namespace visibility for classes, interfaces
> or
> > traits (already discussed here:
> https://wiki.php.net/rfc/namespace-visibility).
> > It's about
> On Sep 17, 2020, at 8:28 AM, Olle Härstedt wrote:
>
> (NB: This idea is NOT about namespace visibility for classes, interfaces or
> traits (already discussed here:
> https://wiki.php.net/rfc/namespace-visibility).
> It's about adding a *new* visibility qualifier, call it "internal", to
>
On Tue, Aug 10, 2010 at 21:56, Christian Kaps christian.k...@mohiva.com wrote:
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a namespace. This ends up
with many class constants like const NS_SEPARATOR = '\\'. A
On Tue, Aug 10, 2010 at 9:59 PM, Daniel Egeberg daniel.egeb...@gmail.comwrote:
On Tue, Aug 10, 2010 at 21:56, Christian Kaps christian.k...@mohiva.com
wrote:
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a
On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
like DIRECTORY_SEPARATOR I guess
Tyrael
but, DIRECTORY_SEPARATOR is system dependent. The namespace separator is
not. It is is always \.
--
Brian.
http://brian.moonspot.net/
--
PHP Internals - PHP Runtime Development Mailing List
To
Am 10.08.2010 22:07, schrieb Brian Moon:
On 8/10/10 3:03 PM, Ferenc Kovacs wrote:
like DIRECTORY_SEPARATOR I guess
Tyrael
but, DIRECTORY_SEPARATOR is system dependent. The namespace separator
is not. It is is always \.
OK. This is clear.
--
PHP Internals - PHP Runtime Development
Hello Christian
2010/8/10 Christian Kaps christian.k...@mohiva.com:
Hi,
is there any reason why no namespace separator constant exists in PHP. I
have many cases where I concatenate strings to a namespace. This ends up
with many class constants like const NS_SEPARATOR = '\\'. A default PHP
Hi,
Em Seg, 2008-11-10 às 15:51 +0100, Timm Friebe escreveu:
Hi,
easy one: Two of the namespace tests in Zend/tests don't use the new ns
separator yet:
http://sitten-polizei.de/php/zend-test-ns-separator.diff
- Timm
Opsss :) Thanks Timm!
--
Regards,
Felipe Pena
--
PHP Internals
Marshall Greenblatt wrote:
Hi Stas, and All,
I understand that there is a strong desire for this thread to be dead.
However, after reading this and all related threads and wiki, I find that
one item is still unclear, at least to me.
On Mon, Oct 27, 2008 at 6:27 PM, Stanislav Malyshev
On 05.11.2008, at 01:05, Stanislav Malyshev wrote:
Hi!
or in other words give the user the ability to specify when he
wants the
fallback to global and not doing a fallback to global per default.
That way
This would be quite complex thing since this way you can't be sure
which class
Lukas Kahwe Smith wrote:
On 05.11.2008, at 01:05, Stanislav Malyshev wrote:
Hi!
or in other words give the user the ability to specify when he wants
the
fallback to global and not doing a fallback to global per default.
That way
This would be quite complex thing since this way you can't
On 05.11.2008, at 21:24, Stanislav Malyshev wrote:
Hi!
Well, its not like the person is getting Y when he is expecting X.
Both classes have the same name after all, so there is some
relation between
They don't have the same name - two classes can't have the same
name. And relation is
Hi!
ok, they have the same non fully qualified named.
That's why we should have unambiguous resolution mechanism. You propose
to add one ambiguity on top of another.
want to get generic \Exception instead of \My\Very\Specific\Exception
- it would probably break all your error handling.
Hi!
Well, its not like the person is getting Y when he is expecting X. Both
classes have the same name after all, so there is some relation between
They don't have the same name - two classes can't have the same name.
And relation is definitely not enough - you really do not want to get
On 31.10.2008, at 19:02, Lukas Kahwe Smith wrote:
Hi
I have tried to collect the various opinions on resolution order
into a single RFC:
http://wiki.php.net/rfc/namespaceresolution
Proactive damage control:
I have also included some discussion on how the removable of
function/constants
Lukas Kahwe Smith wrote:
one could also do
1) ns
2) global
3) autoload
I'm in favour of this (if it avoids performance problems) as I don't see
a problem with giving global priority over autoload.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 04.11.2008, at 17:15, Gregory Beaver wrote:
In other words, it is perfectly all right to have a different name
resolution for classes than we have for functions and constants
because
of this different expectation. It is dangerous to fallback for
classes
prior to autoload, but it is
Hi Greg, all,
For this reason, the only resolution that we should be considering is:
classes:
1) try ns::class
2) autoload ns::class
3) fail
functions/constants:
1) try ns::function/ns::const
2) try internal function/const
3) fail.
I see this as giving priority to library authors rather
Hello Steph,
Tuesday, November 4, 2008, 5:44:50 PM, you wrote:
Hi Greg, all,
For this reason, the only resolution that we should be considering is:
classes:
1) try ns::class
2) autoload ns::class
3) fail
functions/constants:
1) try ns::function/ns::const
2) try internal
What am I missing?
That INI is the worst we could do. Because it prevents from writing
portable code.
This particular INI doesn't prevent anyone writing portable code. It simply
gives the option of a 'tighter' development mode.
- Steph
--
PHP Internals - PHP Runtime Development Mailing
IT will break the code from everybody who doesn'T expect such a flag
exists and the average application user won't know and jsut see errors
which randomly occur.
Erm, how is that going to happen?
This is basically a tighter setting that can *optionally* be used and should
*always* be used in
On Tuesday 04 November 2008 17:44:50 Steph Fox wrote:
We could have an INI_SYSTEM switch.
ns.lookup=Off
means you _have_ to prefix because otherwise resolution will fail with a
fatal error, but
ns.lookup=On
means that anything not prefixed and not local goes through the full
lookup,
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
Distributed to user, that has ns.lookup=On as you propose, user borks his
install, lacks the file containing the class, gets the global class -
obscure error messages because of nonexisting methods in places unrelated
to
On Tuesday 04 November 2008 18:27:43 Steph Fox wrote:
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
Distributed to user, that has ns.lookup=On as you propose, user borks his
install, lacks the file containing the class, gets the global class -
obscure error
Christian Schneider wrote:
Lukas Kahwe Smith wrote:
one could also do
1) ns
2) global
3) autoload
I'm in favour of this (if it avoids performance problems) as I don't see
a problem with giving global priority over autoload.
Hi,
This is the current name resolution. The problem is that:
On Tue, 2008-11-04 at 16:48 +, Steph Fox wrote:
What am I missing?
That INI is the worst we could do. Because it prevents from writing
portable code.
This particular INI doesn't prevent anyone writing portable code. It simply
gives the option of a 'tighter' development mode.
IT
Lukas Kahwe Smith wrote:
On 04.11.2008, at 17:15, Gregory Beaver wrote:
In other words, it is perfectly all right to have a different name
resolution for classes than we have for functions and constants because
of this different expectation. It is dangerous to fallback for classes
prior
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
Distributed to user, that has ns.lookup=On as you propose, user borks
his
install, lacks the file containing the class, gets the global class -
obscure error messages because of nonexisting methods in places
Hi Greg,
By doing the resolution I've suggested (and Stas, incidentally, was the
first to suggest this):
classes:
1) ns\class
2) autoload ns\class
3) FAILBOAT
functions/constants:
1) ns\func or ns\const
2) internal func\const
3) FAILBOAT
We get the best of #1 and the best of #2, and it makes
Steph Fox wrote:
IT will break the code from everybody who doesn'T expect such a flag
exists and the average application user won't know and jsut see errors
which randomly occur.
Erm, how is that going to happen?
This is basically a tighter setting that can *optionally* be used and
should
Ryan Panning wrote:
use 'NsA\NsB\NsC\func_c()';
OMG That looks UGLY1
$obj = new NsA\NsB\ClassB;
$obj-methodB();
func_c();
?
Best,
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 04.11.2008, at 18:59, Gregory Beaver wrote:
#2 means we want to be able to access stuff like strlen() and
array_map() without any monkey business.
snip
functions/constants:
1) ns\func or ns\const
2) internal func\const
3) FAILBOAT
Right, for the most part people will want access to
As you pointed out, there is no autoload for functions, so people are
accustomed to ensuring that all functions are loaded before usage. Am I
missing something?
Yes - you're missing the possibility of overriding, AKA naming collisions
between internal and userspace funcs/consts.
- Steph
2008/11/4 Andrey Hristov [EMAIL PROTECTED]
Ryan Panning wrote:
use 'NsA\NsB\NsC\func_c()';
OMG That looks UGLY1
This is exactly the kind of comment that is both useless and pointless.
Could you please make sure that you have a valid point with a subject,
arguments, examples
On 05.11.2008, at 00:12, Marcus Boerger wrote:
classes:
1) try ns::class
2) autoload ns::class
3) fail
Since we can stack autoload we could provide a c-level autoload
function
that does the default lookup.
function global_autoload($name) {
if (($p = strrpos($name, '\\')) !== false) {
Hello Lukas,
Wednesday, November 5, 2008, 12:32:19 AM, you wrote:
On 05.11.2008, at 00:12, Marcus Boerger wrote:
classes:
1) try ns::class
2) autoload ns::class
3) fail
Since we can stack autoload we could provide a c-level autoload
function
that does the default lookup.
function
Hello Gregory,
Tuesday, November 4, 2008, 5:15:35 PM, you wrote:
Christian Schneider wrote:
Lukas Kahwe Smith wrote:
one could also do
1) ns
2) global
3) autoload
I'm in favour of this (if it avoids performance problems) as I don't see
a problem with giving global priority over
Hi!
or in other words give the user the ability to specify when he wants the
fallback to global and not doing a fallback to global per default. That way
This would be quite complex thing since this way you can't be sure which
class gets loaded when you say, e.g., Exception - and thus, if you
Note that I say try internal because the only purpose behind allowing
this is to make it easier to use PHP's built-in functionality. Any
userspace stuff should be specifically \prefixed or imported via use.
And (yes) we need import for functions.
Greg
P.S. my mail server has been down for
Hi
I have tried to collect the various opinions on resolution order into
a single RFC:
http://wiki.php.net/rfc/namespaceresolution
Proactive damage control:
I have also included some discussion on how the removable of function/
constants would affect the question of namespace resolution
Hello marius,
typical slashdot php artical. 'PHP is the worst crap ever - god bless
perl' The issue in this case is a confused user. See other mails to
do it right and an archive of thousands of mails discussing the topic (and
no, I am not kidding about that amount). And I have more
Hello Greg,
thanks for finalizing this.
marcus
Sunday, October 26, 2008, 4:37:37 PM, you wrote:
Hi all,
Let me make this brief: there will be lots of complaining about the
namespace separator.
Stop. Now.
It serves no possible useful purpose. If you want to discuss why this
was
Hi!
What, if any, performance penalty should we expect with the proposed
namespace changes when executing existing code that does not use
namespaces? Do we need to change existing namespace-free code in order
If you don't use namespaces, none I guess (well, compiling would be a
little
Greg Beaver wrote:
Hi all,
Let me make this brief: there will be lots of complaining about the
namespace separator.
Stop. Now.
And if you had the common decency not to change the thread-id and subject
some on this list might respect the spirit of your plea.
--
PHP Internals - PHP
William A. Rowe, Jr. wrote:
Greg Beaver wrote:
Hi all,
Let me make this brief: there will be lots of complaining about the
namespace separator.
Stop. Now.
And if you had the common decency not to change the thread-id and subject
some on this list might respect the spirit of your plea.
William A. Rowe, Jr. wrote:
Greg Beaver wrote:
Hi all,
Let me make this brief: there will be lots of complaining about the
namespace separator.
Stop. Now.
And if you had the common decency not to change the thread-id and subject
some on this list might respect the spirit of
Lukas Kahwe Smith schrieb:
Now the people that were not able to attend this IRC meeting can
either accept that there was a sufficient number of people to make
a final decision on something that everybody (obviously also people
who did not attend the meeting) had plenty of time to make their
Greg Beaver schrieb:
I stand by my obvious public intent with the multiple emails, RFCs and
patches I have sent.
Just to make it clear: I appreciate your effort and work on namespaces,
but AFAICS there is no single/complete RFC, only bits and pieces
(problems with the current implementation,
Greg Beaver schrieb:
It was mentioned on IRC that internal functions have to be
prefixed with \ when used in a namespaced file. Without a fallback.
This is not true, and the unit tests demonstrate that
Thank you for clearing this up.
1) check for namespaced\functionname
2) check for
On Mon, Oct 27, 2008 at 15:09, Sebastian Bergmann
[EMAIL PROTECTED] wrote:
Lukas Kahwe Smith schrieb:
Now the people that were not able to attend this IRC meeting can
either accept that there was a sufficient number of people to make
a final decision on something that everybody (obviously also
Hannes Magnusson schrieb:
What exactly are you expecting other then the various wiki entries
and README.namespaces in CVS?
Right, various sources of information that are not neccessarily in
sync and/or up to date.
--
Sebastian Bergmann http://sebastian-bergmann.de/
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
That's the wrong way to do it - it means every time you mention the
internal class name without prefixing it with \ you get exhaustive
autoloading search and nothing tells you about
Stanislav Malyshev wrote:
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
That's the wrong way to do it - it means every time you mention the
internal class name without prefixing it with \ you get exhaustive
autoloading search
2008/10/27 Rodrigo Saboya [EMAIL PROTECTED]:
I agree with Stas. It's better to force people to actually reference their
classes/functions/constants correctly and get better performance than
getting unclear slowdowns.
If I'm not mistaken, you only experience any noticeable slowdown if
all of
Hi!
- you use an internal class many, many times (as the overhead from a
handful of invocations would be negligible)
Actually, one time is enough, as it can bring an application from
essentially zero disk accesses (with bytecode caching) to multiple disk
accesses (to traverse full include
It doesn't take a lot to kill an application if using internal class causes
__autoload to run for a non-existing user class.
Neither caches not optimizations can avoid that, as you can't have something
cached which doesn't exist.
In my autoloader for example, an existing user class is
2008/10/27 Stanislav Malyshev [EMAIL PROTECTED]:
Actually, one time is enough, as it can bring an application from
essentially zero disk accesses (with bytecode caching) to multiple disk
accesses (to traverse full include path to exhaust all autoloading
capabilities).
So we're talking about
Hi!
Then, if we assume that most people will use the global namespace
without prefixing it, what would be the best resolution order for
them? (you didn't mention it in your previous message)
Using the prefixed names.
People who care about performance are supposed to profile their
code... I
2008/10/27 Stanislav Malyshev [EMAIL PROTECTED]:
Then, if we assume that most people will use the global namespace
without prefixing it, what would be the best resolution order for
them? (you didn't mention it in your previous message)
Using the prefixed names.
I'm sorry but I still don't
Hi!
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) check for internal classname
How would you reorder those?
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) fail
...but didn't you say one time is enough? According to your own
2008/10/27 Stanislav Malyshev [EMAIL PROTECTED]:
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) fail
Ok, that makes some sense wrt your position, which I originally
interpreted as namespace/internal/autoload.
You want to force users to use the full name at all
You want to force users to use the full name at all times. IOW, you
want to sacrifice convenience for performance.
(chiming in because it seems that we're overlooking something obvious
here)
If it comes down to this, I'd prefer to see an E_NOTICE for the bad
performance use, though I
On 27.10.2008, at 22:27, Sean Coates wrote:
You want to force users to use the full name at all times. IOW, you
want to sacrifice convenience for performance.
(chiming in because it seems that we're overlooking something
obvious here)
If it comes down to this, I'd prefer to see an
Hi!
this seems like a very good idea to me. this way things default to just
work (which imho is the PHP spirit), while its brain dead easy to
detect misuse.
They not just work - they work in a wrong way (not usable in any
practical application). And E_NOTICE is a non-solution here - if we
On 27.10.2008, at 23:01, Stanislav Malyshev wrote:
Hi!
this seems like a very good idea to me. this way things default to
just work (which imho is the PHP spirit), while its brain dead
easy to detect misuse.
They not just work - they work in a wrong way (not usable in any
practical
Hi!
just the same reason as you can use a constant without initialization.
out of the box PHP does not try to be a teacher. it lets you write you
Constant without initialization doesn't lead to any problems. This one
does.
this is how PHP got its huge userbase. we let people grow with
On 27.10.2008, at 23:27, Stanislav Malyshev wrote:
this is how PHP got its huge userbase. we let people grow with
their needs.
And how exactly it serves the needs of people by secretly making
their applications orders of magnitude slower, and then saying oh,
that's because you failed to
Josh Davis wrote:
2008/10/27 Stanislav Malyshev [EMAIL PROTECTED]:
1) check for namespaced\classname
2) try to autoload namespaced\classname
3) fail
Ok, that makes some sense wrt your position, which I originally
interpreted as namespace/internal/autoload.
You want to force users to
Hi Stas, and All,
I understand that there is a strong desire for this thread to be dead.
However, after reading this and all related threads and wiki, I find that
one item is still unclear, at least to me.
On Mon, Oct 27, 2008 at 6:27 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
And how
Greg Beaver wrote:
The decision is made, now I suggest everyone get busy actually trying
it out.
How are we supposed to try it out? There is no updated implementation
yet, and I would rather discuss a specification instead.
It was mentioned on IRC that internal functions have to be prefixed
On 26.10.2008, at 19:07, Sebastian Bergmann wrote:
Greg Beaver wrote:
The decision is made, now I suggest everyone get busy actually trying
it out.
How are we supposed to try it out? There is no updated implementation
yet, and I would rather discuss a specification instead.
It was
Sebastian Bergmann wrote:
Greg Beaver wrote:
The decision is made, now I suggest everyone get busy actually trying
it out.
How are we supposed to try it out? There is no updated implementation
yet, and I would rather discuss a specification instead.
As Steph pointed out, I toiled for
Hi Lukas,
On Sun, Oct 26, 2008 at 11:28 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Sebastian, you have not participated in the discussion so far. Now you post
a rumor you picked up on IRC into an already heated situation. You do know
full well that it does not require you to point out that
On 26.10.2008, at 21:59, Pierre Joye wrote:
Hi Lukas,
On Sun, Oct 26, 2008 at 11:28 AM, Lukas Kahwe Smith [EMAIL PROTECTED]
wrote:
Sebastian, you have not participated in the discussion so far. Now
you post
a rumor you picked up on IRC into an already heated situation. You
do know
full
On Sun, Oct 26, 2008 at 2:11 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
As was evident from the discussions in the past weeks, a lot of people
commented, most of which did not spend the necessary time to actually
understand the issues at hand. Given that it did indeed make it impossible
to
Hi Pierre,
Excuse me but while the idea to have an online meeting was great,
sending a mail to ask to attend an online meeting 24 hours before and
on a Friday was not a wised choice. I would have participated too if
it was during this week or the next weekend.
You were actually online
On 26.10.2008, at 22:19, Pierre Joye wrote:
To make my point more clear: I respect the decision even if I'm not
completely happy about it (that's what we call a compromise). But my
comment to Greg and Steph was about the danger of abusing of private
discussions not about having held this
On Sun, Oct 26, 2008 at 2:24 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hi Pierre,
Excuse me but while the idea to have an online meeting was great,
sending a mail to ask to attend an online meeting 24 hours before and
on a Friday was not a wised choice. I would have participated too if
it was
On Sun, Oct 26, 2008 at 22:19, Pierre Joye [EMAIL PROTECTED] wrote:
To make my point more clear: I respect the decision even if I'm not
completely happy about it
As do I. So lets kill this thread, unless you want the cool slashdot
guys to post more FUD referencing this thread.
-Hannes
--
Pierre Joye wrote:
@Greg and Steph: Private discussions are bad. Or are you trying to say
that this list can't be used as a discussion platform (even heated)?
If we like to have a developer only list, let do it, but keep things
in the public area, that's the only way to keep our decision
On Sun, Oct 26, 2008 at 2:37 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hey Pierre,
You were actually online throughout it, and were notified that it was
happening at the start. In fact you were the first person to blog the
outcome of the meeting.
I'm always online, bot/proxy.
You should be
hi Greg,
On Sun, Oct 26, 2008 at 3:01 PM, Greg Beaver [EMAIL PROTECTED] wrote:
Go ahead and attack my character if you feel it serves some purpose and
benefits PHP. I on the other hand will continue to post actual
solutions, patches and discuss them.
I'm not sure what's the hell is going on
Hi,
I'm not sure what's the hell is going on with you and Step,
OK, Pierre. You got us. Greg and I have been secret lovers for the last 5
years and we've been planning to take over php.net the whole of that time.
but if we
can't answer to any of your mails without being accused of
Yes, it does not mean that I was able to actually attend the meeting.
Because... oh wait. It wasn't important to you.
OK OK I'm not going to push this publicly. Just pointing out that most of
us
keep irc logs.
Preaching by example.
I didn't want to push this publicly, Pierre. Remember
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,
1 - 100 of 273 matches
Mail list logo
