php.net irc log namespaces

[16:00:19] <@dmitry> hi, have we started?
[16:00:35] <@CelloG> hi dmitry
[16:00:38] <@otherbird> not really - just greg's been correcting errors on his wiki page
[16:00:54] <@otherbird> have you had a chance to look through it yet?
[16:01:01] <@dmitry> yeah it has some mistakes
[16:01:10] <@otherbird> please share :)
[16:01:14] <@dmitry> of course
[16:02:38] <@CelloG> if it didn't, I would be ashamed of myself - I wrote it in a single blast after 1 AM, and proofreading doesn't help much for me in that state :)
[16:02:41] <@dmitry> The name resolution bug in "\" proposal in second paragraph after two examples is not really a bug
[16:02:47] Derick__ joined the channel.
[16:03:00] Derick is now known as Derick___.
[16:03:02] Derick__ is now known as Derick.
[16:03:11] lsmith sets mode +o Derick
[16:03:18] <@dmitry> if we have a name in namespace we always assume that it's a local namespaced name
[16:03:19] <@CelloG> here? http://wiki.php.net/rfc/backslashnamespaces#resolution_of_t_string_t_paamayim_nekudotayim_t_string_and_why_this_kills_as_namespace_separator
[16:03:38] <@CelloG> dmitry: that's not how it is implemented
[16:04:04] <@CelloG> if we have foo::bar::foo() inside a namespace, it resolves to "foo::bar::foo()" without namespace prefix
[16:04:17] <@CelloG> as if it were ::foo::bar::foo()
[16:04:35] <@dmitry> so in namespace foo::bar always assumes method bar in namespace foo
[16:04:36] <@CelloG> and the same is true of foo::bar()
[16:04:46] <@CelloG> no - it resolves to class foo, method bar
[16:04:49] <@CelloG> which is the bug
[16:04:59] Derick___ left IRC. (leaving)
[16:05:16] <@dmitry> right
[16:05:27] <@CelloG> it should resolve to namespace function
[16:05:30] <@dmitry> we have different resloutions orders for short and long names
[16:05:41] <@dmitry> long names are used right as is
[16:06:17] <@CelloG> the same problem exists for classes in sub-namespaces
[16:06:19] <@dmitry> short names in namespaces assumes entities from namespace
[16:06:33] <@otherbird> when you say 'long names' you mean the fully resolved path, right?
[16:06:38] <@CelloG> any name containing ::
[16:06:43] <@dmitry> we don't handle sub namespaces
[16:07:05] <@dmitry> the name of subnamespace must be written completely
[16:07:05] <@otherbird> ...
[16:07:05] <@CelloG> well, the bug is that it makes the same code work very differently in and outside of a namespace
[16:07:15] <@dmitry> or it must be imported
[16:08:20] <@CelloG> is there something I need to correct on the RFC or was this a misunderstanding?  I am saying that the way we do things now leads to non-intuitive behavior from the engine, which = bug
[16:09:18] <@CelloG> i.e. foo::bar might be a short name - class foo, method bar, but it could also be a long name, function foo::bar
[16:09:25] <@CelloG> and the engine just assumes it is a short name
[16:09:36] <@CelloG> and that is why :: is fatally flawed as a separator
[16:09:36] <@Derick> and it's confusing for me read
[16:09:44] <@otherbird> Dmitry: what's the problem with the classes-only approach? I can't see why functions would be anything other than global in that scenario?
[16:09:51] <@dmitry> Anyway "\" is not an option
[16:09:54] <@CelloG> because there is no way to check for both unless we retool the way we check names completely
[16:09:57] <@Derick> dmitry: why not?
[16:10:05] <@otherbird> what derick said
[16:10:06] auroraeos joined the channel.
[16:10:07] <@CelloG> ... I wrote a working patch, how is it not an option?
[16:10:11] <@CelloG> hi elizabeth
[16:10:13] <@dmitry> try to writre namespace name in a duble quoted string
[16:10:15] * auroraeos waves
[16:10:17] <@Derick> hi
[16:10:23] <@CelloG> "like\\this\\works\\fine"
[16:10:27] <@Derick> dmitry: why would I want to do that?
[16:10:32] <@dmitry> echo "my\namespace"
[16:10:34] <@otherbird> dmitry: greg already covered that
[16:10:34] <@CelloG> several tests do it
[16:10:43] <@CelloG> so it is possible, but is a drawback
[16:11:07] <@johannes_> some factory implementations do that, too, for doing new $string; then
[16:11:54] <@CelloG> what happens is a fatal error, class not found "namewithweirdcharacters"
[16:12:19] <@CelloG> one of the tests was failing because \f is some kind of control sequence, so it could be an issue and is one to take seriously
[16:12:21] <@otherbird> and don't whatever you do name anything beginning with n or t :)
[16:12:27] <@otherbird> or f...
[16:12:44] <@CelloG> no, whatever you do, use \\ inside a double quoted string if you want \
[16:13:00] <@Derick> or use single quoted strings
[16:13:01] <@CelloG> which is a rule that all PHPers know, and yet it is easy to screw up
[16:13:07] <@CelloG> which is what I do these days
[16:13:14] <@CelloG> (single quoted)
[16:13:23] <@otherbird> the longer we look at this the more I'm thinking a full ns implementation would need to wait to 6.0
[16:13:35] <@bjori> +1 on classes only :)
[16:13:48] <@otherbird> bjori: that's where I am right now too
[16:13:54] <@otherbird> keep it simple
[16:14:00] <@Derick> otherbird: waiting doesn't help though
[16:14:08] <@bjori> rome wasnt build in a day
[16:14:09] <@Derick> it still needs to be sorted out properly
[16:14:14] <@dmitry> with classes only we have to emit a fatal error on each function declaration in namespace
[16:14:19] <@CelloG> let's talk about that
[16:14:26] <@otherbird> Derick: no, but a patch the size of Greg's shouldn't go into the engine so late in the release cycle
[16:14:27] <@bjori> dmitry: thats fine
[16:14:44] <@CelloG> otherbird: it's deceptive, most of that patch is generated source and modified test files
[16:14:51] <@Derick> otherbird: meta-discussion, irrelevant now
[16:14:53] <@CelloG> there's about 200ish actual line changes
[16:15:01] <@dmitry> and we probably have to remove "const = X;"  syntax as it became useless
[16:15:14] <@bjori> I never understand that point anyway dmitry
[16:15:19] <@dmitry> then namespaces with classes only can work
[16:15:31] <@bjori> and the drawbacks with that are?
[16:15:43] <@otherbird> why do we have to emit a fatal error?
[16:15:54] <@bjori> no, but why wouldnt you?
[16:16:06] <@CelloG> http://wiki.php.net/rfc/backslashnamespaces#remove_functionsconstants_from_namespaces
[16:16:10] <@bjori> it doesn't do what you think it would do, so a fatal error rather then obscure behaviour is better
[16:16:15] <@otherbird> I'd assume that classes were ns'd and functions weren't, simple as
[16:16:23] <@CelloG> nobody else would think that way
[16:16:32] <@otherbird> warning?
[16:16:35] <@CelloG> it would be like being able to define methods inside class {} that don't go in the class
[16:16:36] <@otherbird> :)
[16:16:37] <@johannes_> I like the const foo = "bar"; syntax, even in global scope ...
[16:17:04] <@dmitry> but it'll prohibited in namespaces
[16:17:08] <@otherbird> CelloG: point taken, I was thinking more of when you're using third-party ns'd stuff in your own non-00 codebase
[16:17:30] <@CelloG> otherbird: think of taking existing code and putting a namespace declaration at the top
[16:17:43] <@CelloG> it would require splitting files in many cases
[16:17:55] <@CelloG> even in OO projects, we use functions for sort callbacks all the time in PEAR
[16:18:09] <@CelloG> which could be replaced with closures, but there are other examples as well
[16:18:14] <@otherbird> so why not make it global? it would seem the sanest thing
[16:18:17] <@bjori> KISS. Only classes in namespaces. See how it pans out. If it works out cool, and people want to evolve to do otherstuff in namespaces then we can go over the options again
[16:18:21] <@otherbird> s/make/keep
[16:18:32] <@bjori> otherbird: but it could break BC if functions will ever be allowed
[16:18:34] <@otherbird> bjori: that's not an option, we already know that
[16:18:46] <@otherbird> we either allow for them now, or we don't
[16:18:48] <@CelloG> the only way I would support removing functions/constants would be if it is actually possible to add them back in
[16:18:50] <@otherbird> (ever)
[16:19:03] <@Derick> CelloG: and that can only be done by solving the issues with them right now
[16:19:31] <@CelloG> and there are 2 ways we can do that.  (1) change :: to \ as separator (2) have different syntax for accessing functions/consts as in nsname::here::is->constantname
[16:19:54] <@CelloG> we both know #2 has been regarded as alien syntax by many
[16:19:55] <@Derick> CelloG: and I am quite against (2)
[16:20:01] <@CelloG> s/both/all/
[16:20:13] <@otherbird> so let's investigate (2), because we don't know much about it
[16:20:37] <@CelloG> #2 would mean that $a = nsname::classname and $a = nsname->classname();
[16:20:45] <@dmitry> what about the idea of changing resolution order from (function->class) to (class->function)?
[16:20:47] <@CelloG> it's the reverse idea of Stas's Classname->method() syntax
[16:21:03] <@CelloG> dmitry: introduces autoload bomb on all namespaced function calls
[16:21:09] <@otherbird> the *reverse* idea? where'd this one come from?
[16:21:10] <@dmitry> I know
[16:21:11] <@CelloG> I already suggested it, and Stas vetoed on those grounds
[16:21:26] <@CelloG> it can introduce a hidden order-of-magnitude performance problem
[16:21:27] * Derick would agree
[16:21:39] <@dmitry> but we can think about caching negative autholod results
[16:21:49] <@CelloG> it still means at least 1 call per file
[16:21:57] <@CelloG> since namespaces are per-file
[16:21:58] <@dmitry> it's an implementation  question
[16:22:12] <@CelloG> and I've spent the better part of the last month trying to solve those questions - it isn't possible
[16:22:17] <@dmitry> 1 call for namespace/class
[16:22:35] <@Derick> if "using \ in double quoted" string is the only real issue with \ as separator -> why are we still discussing it?
[16:22:42] <@dmitry> and this may allow autoload namespaces without classes
[16:22:54] <@CelloG> as much as I would prefer it, it is a deceptive solution, it makes functions dangerous to use in namespaces if you mix them with an OO framework that has autoload
[16:23:11] <@CelloG> derick: the other issue is the size and scope of the changes
[16:23:20] CelloG sets mode +o auroraeos
[16:23:21] <@Derick> CelloG: that's an implementation issue
[16:23:34] <@CelloG> it's a delay-of-release issue, as I understand it
[16:23:35] <@Derick> also "all existing namespaced code must be nearly rewritten, a simple search/replace of :: would not be possible." is not an issue
[16:23:37] <@dmitry> the main issue with \ is readability
[16:23:39] <@Derick> namespaces don't exist
[16:23:43] <@otherbird> Derick: it's whether it's safe at this stage in 5.3 cycle
[16:23:47] <@Derick> dmitry: ::: has also readability issues
[16:24:00] <@bjori> \is hard to type
[16:24:11] <@dmitry> I never liked :::
[16:24:15] <@Derick> bjori: and ::: is not?
[16:24:16] <@otherbird> Derick: ::: was voted out because a sizeable minority have problems even reading it
[16:24:20] <@Derick> i keep typing :: and ::::
[16:24:20] <@CelloG> http://php.net/~helly/triplecolon-colored.html
[16:24:25] <@bjori> Derick: shift+dot*3, not thats easy
[16:24:28] <@CelloG> http://php.net/~helly/backslash-colored.html
[16:24:40] <@CelloG> gives a good sense of how they would look for readability
[16:24:51] <@otherbird> bjori: switch to US layout ;)
[16:24:53] <@bjori> typing \ is impossible with correct fingerposition
[16:24:57] <@johannes_> I like ::: more than \ if it's only about bikeshed color ...
[16:25:01] <@Derick> bjori: that's just your keyboard - other keyboards have it readibly accessible (UK, US, NO, NL at least)
[16:25:04] <@bjori> :)
[16:25:11] <@CelloG> on my keyboard \ is right above "enter" and is easy to get used to typing
[16:25:20] <@otherbird> johannes_: if ~20% of users can't use it, we can't have it
[16:25:26] <@otherbird> simple as
[16:25:48] <@otherbird> Derick: we heard from 3 nationalities on-list that had problems with it
[16:25:55] <@CelloG> johannes_: it's more about code review than bikeshed color
[16:26:02] <@otherbird> Derick: I checked off-list with a friend in Japan, they're OK with it
[16:26:09] <@Derick> otherbird: those have likely issues with other programming characters as well
[16:26:19] <@bjori> no
[16:26:33] <@CelloG> as was pointed out [] and {} also require double keystrokes one of those keyboards
[16:26:39] <@CelloG> or triple
[16:26:47] <@CelloG> and let's be frank here
[16:26:50] <@johannes_> CelloG: well I doubt that either \ or ::: is better readable, from an objective perspective ...
[16:27:01] <@CelloG> shift-colon colon colon is 3 keystrokes and \ is 1 or 2 keystrokes
[16:27:03] <@CelloG> this is a non-issue
[16:27:05] <@dmitry> as a side step from Stas idea of optional A->foo() syntax we can use <A>::foo() as an alternative syntax
[16:27:10] <@bjori> this is fun :)
[16:27:11] <@otherbird> johannes_: did you look at the stuff Greg put online to demonstrate?
[16:27:18] <@johannes_> (and \ on German keyboard is right Alt key + the one right of the 0)
[16:27:41] <@Derick> dmitry: yes, something like that *could* work perhaps — but I'd need to see an example first
[16:27:51] <@otherbird> dmitry: what Derick said (again)
[16:27:53] <@CelloG> dmitry: yes we could do this too, I thought you had given up on it :)
[16:27:59] <@CelloG> that's the only reason I didn't suggest it
[16:28:06] <@Derick> afk
[16:28:09] <@CelloG> stas was violently opposed to it
[16:28:16] <@otherbird> ?
[16:28:29] <@Derick> CelloG: is violently opposed to everything he doesn't like ;-)
[16:28:48] <@dmitry> I tried the idea of using <A> syntax of namespaces everywhere
[16:28:48] <@johannes_> otherbird: yes, i also wrote some pseudo-code with both of them ... and to *me+ \ was more distrubing, but I guess one could get used to it ...
[16:28:49] <@otherbird> oh that's not fair now, just bc you know he's only logging :)
[16:29:20] <@otherbird> dmitry: do you have some sample code you can put online?
[16:29:24] <@dmitry> but now I'm talking about using it only as an alternative syntax to explicitly call method in ambiguity case
[16:29:39] <@dmitry> (the same as Stas idea with ->)
[16:29:57] <@CelloG> dmitry: the syntax was only part of the problem for me, and the least significant part
[16:29:58] <@otherbird> dmitry: understood - my question about that would be how is ambiguity defined?
[16:30:20] <@CelloG> http://wiki.php.net/rfc/backslashnamespaces#problems2 <-- see the first problem listed
[16:30:23] <@otherbird> by the Engine? (eg a warning is thrown?)
[16:30:51] <@CelloG> warning can't be thrown - that introduces autoload bomb
[16:31:05] <@CelloG> i.e. the engine can't detect the ambiguity without calling autoload
[16:31:08] <@dmitry> A::B::foo(), is it a method of A in ns B, or function foo in ns A::B
[16:31:29] <@dmitry> right
[16:31:58] <@dmitry> so we have to call autoload, but we can do it once for it namespace
[16:32:07] <@dmitry> it=each
[16:32:48] <@otherbird> so... really that's impracticable because it relies on the programmer to know when ambiguity arises
[16:32:48] <@lsmith> <@dmitry> but now I'm talking about using it only as an alternative syntax to explicitly call method in ambiguity case
[16:33:01] <@lsmith> dont you think plain parenthesis are more obvious for this?
[16:33:05] <@otherbird> lsmith: that's how I understood it too
[16:33:16] <@lsmith> also are you talking about having the brackets part of the ns name or not?
[16:33:29] <@dmitry> I like <> more
[16:33:31] <@otherbird> and no to parenthesis, they're used all over the shop as it is :)
[16:33:51] <@dmitry> then [], and only then ()
[16:34:11] <@lsmith> otherbird: thats the point .. this is about resolution order control .. then parenthesis are obvious .. this is what we use in math too
[16:34:13] <@dmitry> however I would accept even ()
[16:34:30] <@lsmith> so its reusing an existing concept for the same purpose
[16:34:41] <@lsmith> instead of introducing a new syntax for an existing concept
[16:34:45] <@otherbird> lsmith: point taken
[16:34:46] <@CelloG> folks, did we all look at the fact that anything that changes classname::method requires rewriting all existing OO code to actually solve the problem?
[16:34:56] <@CelloG> do we seriously think this is a real, practical option?
[16:35:11] <@otherbird> point taken (again)
[16:35:20] <@lsmith> imho its fine to force rewriting if people use ns
[16:35:23] <@dmitry> It requires rewritting only in case ambiguities are really exists
[16:35:28] <@Derick> lsmith: i disagree
[16:35:33] <@lsmith> if it gets a considerably better long term syntax
[16:35:36] <@Derick> lsmith: it'd be a major pain for pear, and also for us
[16:35:36] <@CelloG> it requires rewriting code that uses third-party libraries that use namespaces
[16:35:38] <@dmitry> most cases won;t have any ambiguities
[16:35:41] <@lsmith> (which my E_STRICT proposal was about)
[16:35:50] <@dmitry> ZendFramework don't use functions at all
[16:35:51] * lsmith nods to dmitry
[16:36:20] <@CelloG> look, either we decide this is a problem, or not
[16:36:28] <@CelloG> if we decide it is not a problem, then we don't change syntax
[16:36:33] <@CelloG> no bandaids, please
[16:36:58] <@lsmith> CelloG: i actually think bandaids are legit
[16:37:00] <@otherbird> it's only not a problem if we don't have ns func/const support (ever)
[16:37:07] <@otherbird> lsmith: fail!
[16:37:44] <@lsmith> especially if we make it possible to migrate the code to be nice and clean (with E_STRICT) eventually
[16:37:56] <@CelloG> in this case we are talking about introducing alternate syntax that would bring PHP closer to Perl (many ways to do the same thing for no apparent reason)
[16:38:07] <@lsmith> but i think we all agree now that not having a way to resolve ambiguity is an issue
[16:38:28] <@otherbird> lsmith: only if we take that proposal
[16:38:50] <@otherbird> the \ alternative and the classes-only alternative don't present those problems
[16:39:20] <@lsmith> so for the \ proposal .. what is the real concern we think is the stumbling block?
[16:39:25] <@otherbird> time
[16:39:28] <@dmitry> classes only is good for pure-OO frameworks
[16:39:29] <@CelloG> don't forget the code review issue, both Ilia and Marcus have noted that allowing functions to look like static method calls would prevent major problems in that area
[16:39:34] <@lsmith> i mean what tips this proposal to not be a sure winner?
[16:39:47] <@CelloG> er
[16:39:50] <@CelloG> cause major problems :)
[16:40:18] <@lsmith> if it has major issues .. they do not seem to be listed on the wiki
[16:40:22] <@CelloG> for \ proposal, the major problems to think about are time and readability.
[16:40:23] <@otherbird> lsmith: nothing, it's literally down to class-only vs \
[16:40:24] <@CelloG> uh, check again
[16:40:32] <@CelloG> http://wiki.php.net/rfc/backslashnamespaces#problems3
[16:40:55] <@Derick> CelloG: the only "valid" one is the escaping issue
[16:41:16] <@lsmith> "the patch touches a lot of the engine, and will need rigorous battle-testing." ?
[16:41:16] <@CelloG> Derick: I wrote down every possible problem I could think of, I'm sure others will think of them as well :)
[16:41:20] <@otherbird> that isn't really an issue for doze users, we're used to having to do that anyway
[16:41:30] <@otherbird> lsmith: that's the one for me
[16:41:34] <@CelloG> lsmith: it touches constant, function and class name resolution
[16:41:40] <@otherbird> lsmith: but that's the _only_ one
[16:42:00] <@CelloG> for the obvious reason that we were looking for :: and now look for \
[16:42:04] <@Derick> lsmith: it'd also mean fixing Xdebu (again)
[16:42:08] <@lsmith> so you are worried .. that if we do spend the time .. we will run into a situation where we realize it doesnt work?
[16:42:11] <@Derick> but alas
[16:42:16] <@otherbird> Derick: that's low priority ;)
[16:42:44] <@lsmith> otherwise i do not see time has a stumbling block
[16:42:49] <@otherbird> lsmith: no, it's more a case of it's likely to be buggy
[16:43:04] <@lsmith> buggy just means more time
[16:43:08] <@otherbird> lsmith: it depends how panicked you are about getting 5.3 out
[16:43:21] <@lsmith> finding out in 4 weeks it doesnt work .. that would concern me
[16:43:41] <@lsmith> so are we worried about buggy .. or possibly discovering it doesnt work
[16:43:54] <@otherbird> greg, dmitry: tell him
[16:44:06] <@CelloG> lsmith: no, I'm not worried about that
[16:44:15] <@CelloG> lsmith: more about missed bugs - it definitely works
[16:44:15] <@lsmith> ok .. so its time only
[16:44:38] <@CelloG> time only, yes
[16:44:38] <@otherbird> so you're prepared to wait for 5.3 a while longer so long as this is resolved?
[16:44:40] <@Derick> which means: 5.3 or 6.0
[16:44:44] <@lsmith> so we make an estimate .. and then we decide if we delay 5.3 (do PHP 5.4 or move this ti PHP 6.0)
[16:44:53] <@Derick> i really don't want a 5.4
[16:45:01] <@otherbird> Derick: nobody does
[16:45:03] <@CelloG> I am certain, for instance, that Dmitry would be able to make this a far better patch than I could
[16:45:09] <@lsmith> lets not worry about PHP 5.4 .. lets get an estimate first
[16:45:19] <@CelloG> dmitry: still there?
[16:45:31] <@dmitry> CelloG: which solution?
[16:45:48] <@CelloG> http://wiki.php.net/rfc/backslashnamespaces#patch <-- the patch linked in there
[16:45:50] <@lsmith> i mean all the other issues with \ seem petty to me .. this seems quite obvious as the way to go, since the only major issue with it is time to create the patch
[16:46:11] <@lsmith> all the other proposals have much more noteworthy concerns
[16:46:14] <@otherbird> lsmith: it's the obvious way to go if we want full ns support
[16:46:34] <@CelloG> it took me a week of a couple hours a day to get that patch working - the biggest stumbling block was constants, which is the most ridiculously complicated thing in the world
[16:46:39] <@otherbird> lsmith: class-only is the only serious option, but it'd have to come with a big stamp on it saying 'forever'
[16:46:48] <@dmitry> no, I won't support '\' solution
[16:46:50] <@CelloG> the majority of code changes were constant-related, as we needed different handling code in 5 different files
[16:47:06] <@lsmith> ah dmitry .. what is the issue you see?
[16:47:49] <@dmitry> it's the issue with myself, I can't accept it
[16:47:57] <@Derick> but why not?
[16:47:57] <@otherbird> you think it's fugly?
[16:48:25] <@dmitry> this syntax goes PHP to Perl or something worse
[16:48:43] <@Derick> dmitry: and none of the other ideas <...> or changing :: to -> does?
[16:49:04] <@otherbird> at least there's no ambivalence about this one..
[16:49:12] <@dmitry> any alternative syntax will work
[16:49:18] <@dmitry> -> <> or ()
[16:49:18] <@CelloG> I think dmitry is showing ambivalence :)
[16:50:07] <@auroraeos> heh, I think simply changing the separator is the best way really... i think anything used will feel "weird" at first... people will adapt
[16:50:08] <@CelloG> so you don't think the ambiguity issue is a problem (as I read it)
[16:50:36] <@dmitry> It's not a big problem
[16:50:51] <@Derick> i think it is
[16:50:54] <@CelloG> it seems there are 2 camps, those who don't think it's a problem (and thus any solution that allows dis-ambiguation without call_user_func or reflection is good) and those who do think it is a problem, and the only solutions require syntax changes
[16:51:00] <@dmitry> PHP has very wired references behavior , but it's not a problem
[16:51:15] <@auroraeos> ...the solution I give for most reference problems is "don't use it"
[16:51:24] <@auroraeos> I really don't want namespaces being told the same thing
[16:51:26] <@auroraeos> do you ?
[16:51:43] <@dmitry> don't use functions in namespaces if you don;t like them
[16:52:34] <@dmitry> it doesn't prohibit to use namespace theirselvs
[16:52:36] <@CelloG> um...
[16:52:52] <@otherbird> well if you're going to make functions in ns ambivalent you might as well just say 'classes only', it goes back to that
[16:52:53] <@CelloG> "here's a brand new feature.  Oh, and don't use it if you don't like it"
[16:53:10] <@CelloG> s/ambivalent/ambiguous/
[16:53:20] <@otherbird> yeah, that too
[16:54:38] <@lsmith> dmitry: you dont like using a backslash for anything but escaping? i assume the issue is not with a new separator .. right?
[16:54:41] <@otherbird> dmitry: I don't understand what you have against \ - is it just the choice of separator you don't like, or something else?
[16:54:49] <@otherbird> lsmith: snap
[16:54:54] <@lsmith> so if there would be this magical separator alternative to \ it would all be good for you?
[16:55:11] <@dmitry> \ is a terrible separator
[16:55:17] <@lsmith> k
[16:55:27] <@otherbird> but is that your only complaint about that resolution?
[16:56:01] <@CelloG> http://pear.php.net/~greg/doubledot.php.txt
[16:56:18] <@CelloG> http://pear.php.net/~greg/doublecarat.php.txt
[16:56:30] <@Derick> CelloG: $err = new ..PEAR2..MultiErrors;
[16:56:33] <@Derick>  is wrong ...
[16:56:44] <@Derick> not?
[16:56:48] <@Derick> nm
[16:56:49] <@Derick> :)
[16:57:07] <@CelloG> no it just looks wrong :)
[16:57:16] <@Derick> yeah
[16:57:19] <@CelloG> these are the two major alternatives not considered
[16:57:30] <@otherbird> double carat looks so surprised :)
[16:57:37] <@Derick> ^^ looks like a WoW smile
[16:57:41] <@otherbird> 'wtf am I doing here?'
[16:57:43] <@CelloG> I also tried ** as separator, but it looks like doubly-dereferenced pointer as in **pointer
[16:58:20] <@lsmith> lets use the real arrow char: →
[16:58:21] <@lsmith> ;)
[16:58:23] <@CelloG> I'm happy to consider alternatives, but the truth is, I think that when actually trying them, \ is much simpler for both typing and reading
[16:58:43] <@CelloG> actually trying = taking existing code, and converting it to namespaces
[16:58:49] <@otherbird> dmitry: you still didn't confirm that the choice of separator was your only objection
[16:58:57] <@auroraeos> actually, after playing with \ it's not as bad as I thought too, CelloG
[16:59:19] <@CelloG> I also believe strongly that every separator is terrible.  \ is like democracy.  The worst separator ever conceived except for all the other ones :)
[16:59:22] <@dmitry> I don't think it's possible to find somrthing better then ::
[16:59:29] <@otherbird> auroraeos: yes, I thought it'd be horrible too til I saw greg's code
[16:59:34] <@Derick> but we've already concluded that :: alone causes issues
[16:59:46] <@otherbird> dmitry: what Derick said (again)
[17:00:05] <@CelloG> I am the strongest advocate for :: - every patch I have made up to this one was designed to preserve it, and I am convinced it just isn't technically possible to use it
[17:00:28] <@dmitry> It's better to have some issues them kill the language with unreadable syntax
[17:00:33] <@otherbird> ... except for classes only
[17:00:53] <@CelloG> I agree with you dmitry, I disagree that \ is unreadable.  Unfamiliar, yes
[17:01:41] <@dmitry> yes
[17:02:03] <@lsmith> ok .. i assume we will get the same opinion from Stas ..
[17:02:10] <@dmitry> once agin eval() and code with namespaces
[17:02:16] <@otherbird> lsmith: that's a dangerous assumption
[17:02:41] <@Derick> dmitry: if you use eval, you need to think of escaping anyway
[17:02:45] <@dmitry> eval("$y = a\new_foo($x);");
[17:02:52] <@CelloG> lsmith: I wouldn't assume anything of Stas, he's a surprising fellow
[17:03:25] <@Derick> dmitry: that code is wrong, you need to escape $ too
[17:03:27] <@CelloG> in all cases where \ creates an escape sequence, we get immediate parse error
[17:03:41] <@CelloG> which makes it easy to debug
[17:03:52] <@otherbird> .. which resolves disambiguation issues
[17:04:14] <@CelloG> actually there is 1 case where we would not get a parse erorr
[17:04:25] <@CelloG> when using reflection, or when using constant()
[17:04:30] <@otherbird> where it makes sense to the engine too (f, t, n)
[17:04:34] <@CelloG> but we get a notice with constant, and an exception with reflection
[17:04:38] <@CelloG> so I guess that's the same idea
[17:05:54] <@CelloG> I have a quote from Stas: "I asked a lot of people - including ones that write major OO frameworks and real-life major applications - and they are OK with current solution and I think will be OK with either of the solutions we have under consideration. I think they will be much less OK with ::: and they will be royally pissed off at PHP group if there would be no namespace implementation in 5.3. "
[17:06:03] <@CelloG> so I think it may be fair to assume he won't like \
[17:06:22] <@CelloG> and "If we could find better separator, I think we would have found it by now... I didn't see yet a proposal that didn't look alien to PHP and unobvious to the user."
[17:06:39] <@otherbird> so we should talk to the ones that write major OO frameworks
[17:06:46] <@otherbird> ?
[17:07:25] <@lsmith> i think most of the people that care today are reading internals now
[17:07:31] <@dmitry> We spoke with ZendFramework team and even tryed to use current implementation
[17:07:34] <@lsmith> what was the reaction to \ (or ..)
[17:07:40] <@otherbird> lsmith: yes, but we're hiding from it ;)
[17:07:45] <@lsmith> ?
[17:08:29] <@CelloG> I think we could do that and talk in circles - in my opinion the best course is to decide whether there is a problem with ambiguity or not, and then choose the implementation.  Developers adapt once they decide there is 1 choice if and only if it actually ends up working
[17:08:30] <@otherbird> lsmith: \ or .. hasn't been offered up on-list as a solution, were you asking dmitry?
[17:08:44] <@dmitry> We had problems with naming convesions then some parts of the name were "abstract" or "interface"
[17:08:50] <@otherbird> CelloG: I agree with you
[17:08:51] <@lsmith> otherbird: both separators have been mentioned on the list
[17:09:12] <@lsmith> and atleast \ has been mentioned quite a lot lately
[17:09:16] <@otherbird> lsmith: 'mentioned' yes, not polled - not in the last several years anyway
[17:09:25] <@lsmith> otherbird: err ..
[17:09:49] <@otherbird> no really
[17:09:50] <@CelloG> a poll can't work here.  It's not possible to vote without really understanding the depth of the problem - do you really expect all internals devs to read that long wiki entry I just wrote? :)
[17:09:59] <@lsmith> i think it a lot of people have voiced opinions .. and i remember a lot in favor
[17:10:09] * lsmith nods to CelloG
[17:10:10] <@CelloG> the only separator a lot have voiced favor for is :::
[17:10:23] <@otherbird> CelloG: I would expect them to read up prior to voting, yes
[17:10:23] <@auroraeos> well CelloG, that's not entirely true
[17:10:32] <@CelloG> auroraeos: which part?
[17:10:33] <@otherbird> CelloG: that came second, : came tops
[17:10:38] <@auroraeos> many who voted were saying "change the separator" not necessarily to ':::' but something
[17:10:40] ScottMac joined the channel.
[17:10:46] <@CelloG> right : ain't possible, especially with goto labels
[17:10:56] <@CelloG> auroraeos: right, that is a good point
[17:10:56] * ScottMac is hung over
[17:11:01] <@CelloG> heh hi scott
[17:11:03] CelloG sets mode +o ScottMac
[17:11:09] <@otherbird> CelloG: many in the last poll wanted a different separator, didn't say which, just not :::
[17:11:13] <@lsmith> err .. you guys do know the entire thread that lead to the keyboard discussion?
[17:11:24] <@ScottMac> i saw that
[17:11:36] <@lsmith> anyways .. yeah .. i think the fundamental question to answer first is if we feel that ambuigity is a severe issue or not
[17:11:45] <@CelloG> lsmith: also a good point, many casually mentioned being ok with \
[17:11:48] <@otherbird> lsmith: the kb discussion was short-lived, it's at the end of all ns stuff - Derick and someone else offered workarounds
[17:12:06] <@otherbird> lsmith: I think it self-evidently is
[17:12:15] <@lsmith> i also do not think that ns is a internals poll decision
[17:12:18] <@CelloG> the truth is, ambiguity between namespaced function and static class method will be somewhat rare, just as all edge cases are somewhat rare
[17:12:37] <@CelloG> but the ambiguity goes beyond just actual code in run-time
[17:12:45] <@Derick> CelloG: it'll be harder to explain than that you need to escape \
[17:12:53] <@CelloG> there is a real, and serious problem with debuggability and code review
[17:13:02] <@otherbird> CelloG: that would make it a nightmare to debug those clashes
[17:13:08] <@CelloG> the simple fact that the engine has trouble telling the difference is because they look the same
[17:13:09] <@otherbird> rarity would make it harder
[17:13:09] <@lsmith> static code analysis ..
[17:13:20] <@CelloG> external code review, security audits, static code analysis all suffer
[17:13:25] <@lsmith> right
[17:13:28] andrei_ joined the channel.
[17:13:35] lsmith sets mode -o andrei_
[17:13:38] lsmith sets mode +o andrei_
[17:13:38] <@otherbird> so really we are down to \ or classes-only
[17:13:49] <@lsmith> otherbird: no .. we are down to another separator or class only
[17:13:57] <@andrei_> I was the one who originally proposed \ :)
[17:14:01] <@CelloG> I would contend that it could even open up a new security vulnerability when combined with other problems (user uploads script that is loaded first in include_path and redefined class foo method bar as namespace function foo::bar)
[17:14:03] <@otherbird> lsmith: I stand corrected
[17:14:05] <@otherbird> hi andrei
[17:14:07] <@lsmith> and for the anither separator .. \ is a good candiate
[17:14:12] <@CelloG> hi andrei_ I figured you might like that one for that reason
[17:14:21] <@andrei_> I'm so transparent.
[17:14:32] <@andrei_> did I miss much?
[17:14:33] <@otherbird> you should've written that in black ;)
[17:15:00] <@otherbird> andrei_: sort of, we think we're down to \ vs classes-only but dmitry hates \ enough to refuse to work on it
[17:15:10] <@CelloG> so I have made my opinion clear on the ambiguity, I am happy - no ecstatic - to be proven wrong here by those who feel the ambiguity is not as big of an issue
[17:15:25] <@lsmith> so a quick straw poll .. how is for allowing some syntax for disambigutation, but sticking with ::?
[17:15:28] <@CelloG> because I actually do like ::, just not the baggage associated with it.  :: feels good to use
[17:15:30] <@andrei_> i think :> or -> stuff is worse personally
[17:15:46] <@CelloG> -1
[17:15:51] <@lsmith> dmitry i presume you are?
[17:15:52] <@otherbird> lsmith: -1
[17:15:52] <@dmitry> the same
[17:15:54] <@auroraeos> -1
[17:15:55] <@Derick> -1
[17:16:09] <@andrei_> -1
[17:16:26] <@ScottMac> -1
[17:16:56] <@lsmith> and who is for a new separator? (prefix vote with "new" to make it clear which poll you are voting on)
[17:17:04] <@CelloG> new: +1
[17:17:08] <@Derick> new: +1
[17:17:09] <@dmitry> +1
[17:17:14] <@dmitry> -1
[17:17:17] <@johannes_> new: +1
[17:17:23] <@andrei_> new: +1
[17:17:37] <@otherbird> new: +1 if not class-only
[17:17:49] <@otherbird> dmitry: what on earth are you doing? :)
[17:18:06] <@lsmith> ok .. who is ok with class only? (prefix with class only)
[17:18:17] <@CelloG> class: -1
[17:18:18] <@auroraeos> new +1
[17:18:27] <@Derick> class: -1
[17:18:29] <@auroraeos> class 0
[17:18:29] <@ScottMac> new: +1
[17:18:33] <@ScottMac> class -1
[17:18:36] <@dmitry> 0
[17:18:52] <@andrei_> -1
[17:18:57] <@andrei_> class: -1
[17:18:57] <@lsmith> ok .. counting dmitry as +1, new -1 and class 0
[17:19:02] <@dmitry> (I was too late for first pool +1 is for first and -1 for the second)
[17:19:07] <@otherbird> +1
[17:19:14] <@otherbird> (sorry that was class)
[17:19:44] <@andrei_> I would be majorly disappointed if i coulnd't namespace all the constants in PHP-GTK for example.
[17:19:46] <@lsmith> i am 0, +1 new, -1 class
[17:20:12] <@otherbird> lsmith: ever the diplomat :)
[17:20:15] <@lsmith> ok .. this is quite unanimous .. even if we count Stas to be of the same opinion as dmitry
[17:20:16] <@otherbird> brb
[17:20:17] <@dmitry> in case of classes-only you won't
[17:20:37] <@otherbird> so really the only thing left to discuss is which separator
[17:20:41] <@auroraeos> andrei_: +1 for that...I'd love to get it all namespaced ;)
[17:21:22] <@lsmith> dmitry: i think given the number of core people we have in here .. it seems that we are as close as we will ever be with an agreement
[17:22:00] <@lsmith> i think none of the options on the table will spell the end of php, even though i do think it will certainly have a considerable affect on PHP
[17:22:08] <@dmitry> I see, but selecting separator can take while
[17:22:16] <@andrei_> have we ever discussed disallowing classes inside a namespace to be named the same? that is, namespace Foo cannot contain class Foo?
[17:22:34] <@otherbird> dmitry: it's been discussed sooooooooooo many times surely we already know the problems?
[17:22:55] <@otherbird> dmitry: that's why \ is getting some support now
[17:23:12] <@CelloG> it means doing "sub-namespaces" naming style (like PEAR) with class name + extension cause fatal error
[17:23:36] <@CelloG> it also doesn't remove the visual ambiguity between blah::is::this::method::or::function()
[17:23:40] <@CelloG> it does solve the ambiguity issue in the engine
[17:23:54] <@CelloG> removing that potential security issue I talked about (that would become fatal error)
[17:23:58] <@lsmith> ok .. we are in search of a separator
[17:24:10] <@andrei_> CelloG, I understand that. I bring it up as a possible fallback solution.
[17:24:14] <@lsmith> we have \ on the table as well as the double dot
[17:24:14] * otherbird silently votes for greg's backspace
[17:24:26] <@lsmith> what else?
[17:24:33] <@Derick> ^^
[17:24:35] <@otherbird> lsmith: so you didn't like the eyebrows either? ^^
[17:24:48] <@andrei_> To me personally, \ is a lot easier on the eyes and makes chained namespaces look like a directory search.
[17:24:58] <@CelloG> might as well consider ** since it is technically feasible
[17:24:58] <@lsmith> Derick: why does it need to be double ^?
[17:25:04] <@Derick> ^ is xor
[17:25:06] <@CelloG> single ^ is already used for xor
[17:25:07] <@lsmith> ah right
[17:25:22] <@lsmith> what are some criterias""
[17:25:23] <@otherbird> I wouldn't be opposed to double dot, but I think \ is ok - and it could reflect actual paths to some extent under doze
[17:25:24] <@lsmith> ?
[17:25:25] <@CelloG> % is also possible but holy god almighty it is fugly
[17:25:27] <@lsmith> readability
[17:25:30] <@CelloG> er %
[17:25:34] <@andrei_> eek
[17:25:35] <@CelloG> hrm, double %
[17:25:40] <@lsmith> severity for typos
[17:25:42] <@otherbird> %%namespace
[17:25:45] <@ScottMac> i really dont mind ::: :)
[17:25:48] <@andrei_> we have to consider typography here too. Any "busy" symbol will be tough to read.
[17:26:08] <@lsmith> (as in what would happen if one would do a typo .. this is mainly relevant for the proposals that require double chars)
[17:26:10] <@otherbird> ScottMac: 80% wouldn't, the other 20% have difficulties differentiating it from ::
[17:26:19] <@CelloG> lsmith: ambiguity with other operators (::: looks like ::, \ looks like /)
[17:26:25] <@lsmith> ok
[17:26:26] <@otherbird> actually %% is quite nice
[17:26:41] <@ScottMac> otherbird: an IDE would highlight the difference between ::: and :: quite wel
[17:26:51] <@andrei_> ScottMac, not everyone uses those :)
[17:26:57] <@Derick> ScottMac: it's the typing though... ::: easily turns into :: or ::::
[17:27:01] <@otherbird> ScottMac: what andrei_ said
[17:27:29] <@andrei_> CelloG, different contexts for \ vs /. People are used to seeing / with variables/numbers and in file paths.
[17:27:31] <@ScottMac> how about £ :P
[17:27:40] <@ScottMac> other than the fact most keyboards dont have it
[17:27:42] <@CelloG> http://pear.php.net/~greg/doublepercent.php.txt
[17:27:55] <@CelloG> ScottMac: how do you do that on a US keyboard?
[17:27:56] <@andrei_> ‡
[17:28:11] <@otherbird> you just search and replaced ^^ yeah? now I know why you had ^^ in the first place :)
[17:28:21] <@andrei_> OMG, %% is just not readable to me..
[17:28:37] <@andrei_> it's a "busy" symbol.
[17:28:43] <@lsmith> http://pastebin.com/m4322784a
[17:28:43] <@CelloG> $errs = new %PEAR2%MultiErrors; <-- heheh :)
[17:28:56] <@otherbird> does it even need to be double?
[17:29:00] <@andrei_> i would disagree with this "#
[17:29:01] <@andrei_> \ looks a lot like / and is easy to accidentally flip, especially for unix users
[17:29:01] <@andrei_> "
[17:29:07] <@CelloG> % is modulo
[17:29:08] <@lsmith> is that a summary of the criterias and separators?
[17:29:10] <@andrei_> they are not even close.
[17:29:24] <@otherbird> CelloG: sorry, blonde moment
[17:29:37] <@CelloG> andrei: I made that exact mistake in one of the examples on the RFC and had to correct it this morning
[17:29:45] <@CelloG> foo/name instead of foo\name
[17:29:51] <@andrei_> CelloG, that's cause you've been thinking about it for too long. :)
[17:29:57] <@otherbird> CelloG: but you didn't make it when coding, just when writing about it
[17:30:06] <@andrei_> What about > ?
[17:30:08] <@CelloG> actually, I did make that mistake in one of the unit tests :)
[17:30:14] <@otherbird> CelloG: noted
[17:30:15] <@CelloG> >? greater than?
[17:30:37] <@lsmith> ah right .. we had :> as well
[17:30:37] <@CelloG> lsmith: yes that is a good summary
[17:30:40] <@andrei_> new FileTransactions>Installedas
[17:30:51] <@CelloG> if (CONST > OTHERCONST)
[17:30:51] <@andrei_> I'm looking for a single symbol.
[17:30:55] <@Derick> andrei_: without highlight, hard to see a separator
[17:31:03] <@Derick> as*
[17:31:05] <@CelloG> parser conflict not possible to resolve
[17:31:12] <@andrei_> Derick, fair enough. Which is why I still think \ works the best and has fewest disadvantages.
[17:31:16] <@CelloG> CONST>OTHERCONST could be a namespace constant or an expr
[17:31:21] <@Derick> andrei_: and I agree with that
[17:31:25] <@otherbird> I'd say the advantage of \ is that you only need a single symbol
[17:31:36] <@otherbird> given that we can't have :
[17:31:44] <@otherbird> that goes highly in its favour
[17:31:49] <@andrei_> otherbird, and it's visual correspondence to directory search
[17:32:03] <@otherbird> andrei_: I already said that :)
[17:32:04] <@andrei_> it's = its
[17:32:11] <@andrei_> still drinking coffee here..
[17:32:21] <@otherbird> good thinking, brb
[17:32:25] <@Derick> i've switched to wine already
[17:32:37] <@lsmith> Derick: its before 6pm!
[17:32:43] <@lsmith> tsk tsk
[17:32:50] <@Derick> lsmith: so? :)
[17:33:06] <@andrei_> That's funny, I interpreted it as "I switched to running windows stuff under Wine."
[17:33:07] <@andrei_> doh
[17:33:12] <@lsmith> ok .. i have added :> .. http://pastebin.com/m3a7df988
[17:33:15] <@CelloG> http://pear.php.net/~greg/asshat.php.txt
[17:33:16] <@dmitry> I'm going to take a whiskey :(
[17:33:20] <@Derick> andrei_: wtf would I do that? :)
[17:33:23] <@CelloG> dmitry: :)
[17:33:38] <@andrei_> like i said.. coffee
[17:33:59] <@CelloG> my eyes convert :> to -> or to :: alternately
[17:34:01] <@andrei_> i don't know.. :> just looks weird
[17:34:04] <@andrei_> like a smiley :)
[17:34:09] <@andrei_> CelloG, that too
[17:34:14] <@Derick> »
[17:34:16] <@CelloG> look at static function begin()
[17:34:18] <@andrei_> hey, what about :) separator
[17:34:26] <@Derick> ±
[17:34:26] <@CelloG> in class Installer
[17:34:42] <@Derick> asshat?! :)
[17:34:46] <@lsmith> we could make a ton if we sell PHP NS keyboards :)
[17:35:02] <@CelloG> http://pear.php.net/~greg/smiley.php.txt
[17:35:04] <@andrei_> well, personally I'd still prefer ☭ as a separator
[17:35:09] <@CelloG> Derick: :) I'm glad someone noticed :)
[17:35:12] <@lsmith> andrei_:  :)
[17:35:27] <@Derick> andrei_: haha
[17:35:30] <@CelloG> self::$transact->registerTransaction('rmdir', new FileTransaction:)Rmdir);
[17:35:36] <@CelloG> looks like the ( matches the ) in :)
[17:35:37] <@andrei_> and let's not go into <3
[17:35:37] <@Derick> CelloG: fail
[17:35:50] <@lsmith> CelloG: worse yet .. lots of IDE's will go berserk
[17:36:14] <@lsmith> ok .. i guess we should make a table an rate all the proposals based on the criterias
[17:36:19] <@andrei_> Practically, \ works.
[17:36:22] <@Derick> lsmith: so that excludes <, >, (, ), { and } from any separator
[17:36:37] <@CelloG> for completeness: http://pear.php.net/~greg/doubledereference.php.txt
[17:36:46] <@lsmith> i guess one of us can do this .. then the others can have a look .. and we can talk about any rating someone disputes
[17:36:54] <@lsmith> ok?
[17:37:06] <@Derick> lsmith: criteria: busy symbol, hard to type, IDE berserkyness
[17:37:06] <@dmitry> @
[17:37:07] <@andrei_> CelloG, eek, that smacks of C :)
[17:37:11] <@CelloG> $err = new **PEAR2**MultiErrors; <-- just looks bizarre, especially coming from C background
[17:37:23] <@andrei_> yes, I'd go nuts personally.
[17:37:28] <@Derick> lsmith: number of chars
[17:37:46] <@lsmith> criterias:
[17:37:46] <@lsmith> (1) type-ability (how easy is it to type the separator)
[17:37:46] <@lsmith> (2) typo-vulnerability (how easy is it to make a typo and get an unwanted behavior without a error/warning)
[17:37:46] <@lsmith> (3) parse-ability (how easy is it to read the code and figure out whats going on without getting confused with similar syntax that means another thing)
[17:37:46] <@lsmith> (4) IDE compatibility
[17:37:46] <@lsmith> (5) number of chars
[17:37:52] <@andrei_> those criteria are weighed differently i think
[17:37:59] * CelloG volunteers not to make the table if that's all right
[17:38:24] <@lsmith> andrei_: sure .. but lets worry about that if we have narrowed things doen
[17:38:29] <@lsmith> ok .. i will make the table
[17:38:35] <@lsmith> give me a few mins
[17:38:36] <@CelloG> thanks lukas
[17:38:44] <@Derick> lsmith: (6) busy symbol - how easy it is to spot in unhighlthed text
[17:38:53] * andrei_ is secretly (well, not so much) rooting for \
[17:38:56] <@lsmith> Derick: that is "parse-ability"
[17:39:01] <@Derick> k
[17:39:19] <@CelloG> on a side note, did you all have any idea how uber-complex handling of constants is in the engine?
[17:39:32] <@Derick> CelloG: I know they're slow :)
[17:39:41] <@andrei_> CelloG, Yes.
[17:39:51] <@CelloG> compile-time constants (in method parameter default values, constant values, etc.) are completely different from run-time
[17:40:01] <@andrei_> i know
[17:40:15] <@CelloG> and arrays with constant indices - yikes :)
[17:40:40] <@CelloG> we store metadata in 3 bytes after the constant name and then convert it to its value at runtime
[17:41:02] <@CelloG> that part of the \ patch took me 5 days because of all the complexities I had to learn
[17:42:07] * otherbird hands CelloG a cookie
[17:42:52] <@CelloG> I'd love to talk about http://pastebin.com/m4516ca05
[17:43:24] <@CelloG> if we move to \ as separator, I'd rather require \ prefix for absolute names like an absolute path \foo\bar()
[17:43:26] <@Derick> bar\other\thing
[17:43:31] <@andrei_> agree
[17:43:34] <@otherbird> interesting
[17:43:47] <@CelloG> so that namespace is always prefixed to "relative" namespace names
[17:43:49] <@Derick> because "namespace foo;" is IMO similar to "import foo;"
[17:43:54] <@Derick> which is import foo as foo
[17:43:58] <@andrei_> that would make sense to Web people
[17:44:03] <@dmitry> now it's bar\other\thing
[17:44:16] <@CelloG> no it is bar\other\thing, correct
[17:44:19] <@otherbird> I'd have read that as foo\bar\other\thing because there's no \ in front of it
[17:44:20] <@CelloG> s/no/now/
[17:44:54] <@dmitry> in case you are going to look for \foo\bar\other\thing you have one another ambiguity
[17:45:22] <@CelloG> the confusion I can see is that bar() resolves to foo\bar(), and \bar() resolves to bar()
[17:45:23] <@dmitry> and even for if you have class foo in namespace foo
[17:45:43] <@CelloG> but foo\bar() resolves to foo\bar(), \foo\bar() resolves to foo\bar()
[17:45:46] <@CelloG> it's inconsistent
[17:46:12] <@dmitry> only short names can be resolved now
[17:46:19] <@dmitry> long names are used as is
[17:46:30] <@andrei_> that could work too
[17:46:55] <@CelloG> of course it can work.  There are 2 drawbacks
[17:47:11] <@CelloG> I didn't even understand this until 3 days ago, so newbies will have similar issues
[17:47:28] <@CelloG> and it makes the engine a lot more complex because we have two different ways of resolving things
[17:47:39] <@CelloG> the engine part is just details
[17:47:41] <@Derick> two ways is not "KISS"
[17:48:16] <@CelloG> I could understand it if we document it well, but it's really hard to explain clearly why a short name is different from a long name
[17:48:22] <@lsmith> ok .. here it is:
[17:48:23] <@lsmith> http://pastebin.com/m5a8d7ff1
[17:48:53] <@otherbird> CelloG: well if it's just documentation, I can help - so long as I understand it first :)
[17:49:07] <@lsmith> for type ability is focused on how quick i assume it is to type the chars .. also how common the sign is today already (assuming that people have it in their fingers to quickly type these)
[17:49:23] <@dmitry> again, in case you tey to resolve long names you get another ambiguity which can't be solved with namespace separator
[17:49:34] <@dmitry> yey=try
[17:49:35] <@lsmith> for typo vulnerability i marked down anything that contains an single char operator
[17:49:57] <@lsmith> parse ability anything that looks similar to an existing operator
[17:50:01] <@CelloG> what I did in my patch was to make "relative" always resolve to namespace\...
[17:50:23] <@CelloG> it removes 1 hash lookup from this situation
[17:50:28] <@lsmith> IDE compatibility .. obviously all of the separators show a parse error today .. so i marked down anything that could confuse auto complete or parenthesis matching
[17:50:37] <@lsmith> for number if chars .. i guess its obvious :)
[17:50:54] <@CelloG> #3 should be -1 for \
[17:50:55] <@lsmith> so please raise your hand if you take issue with any of my ratings .. so that we can discuss them
[17:50:55] <@auroraeos> smart IDE 's let you pick a PHP to lint from so won't show a parse error - will just be a highlighting thing ;)
[17:50:58] <@CelloG> it is similar to /
[17:51:20] <@dmitry> then you can't access other namespaces without prefixing them (however in case of \... it looks natural)
[17:51:28] <@lsmith> CelloG: i guess this is for the case when its used inside a string definition only?
[17:51:50] <@CelloG> dmitry: right - that's the drawback.  If we don't use \ as separator, I would prefer existing resolution
[17:52:06] <@lsmith> which would make it +-0 i guess .. but not really -1 .. since its unlikely to be confusing when used outside of a string definition
[17:52:17] <@CelloG> lsmith: I was just talking about $a = CONST / ANOTHER; versus $a = CONST\ANOTHER;
[17:52:32] <@lsmith> ah ok
[17:52:38] <@andrei_> CelloG, true, but i think that's a minor consideration..
[17:52:39] <@CelloG> it's relatively rare to divide two constants, but is possible
[17:52:45] <@lsmith> so lets give it a -1 ..?
[17:52:46] <@CelloG> +-0 is fine, I guess
[17:52:54] <@CelloG> if you all think it's minor
[17:53:01] <@lsmith> opinions?
[17:53:07] <@Derick> 0
[17:53:45] <@CelloG> #2 for :) should be -1 because if we miss the : it becomes a closing paren
[17:54:20] <@lsmith> err yes .. that was a "typo"
[17:54:21] <@lsmith> :)
[17:54:27] <@otherbird> lol
[17:54:29] <@Derick> fail :)
[17:54:37] <@lsmith> http://pastebin.com/m6d4e40f4
[17:54:40] <@Derick> lsmith: should we include ::: too?
[17:54:46] <@otherbird> Derick: no
[17:55:03] <@otherbird> Derick: that was already polled, there are good reasons to drop it
[17:55:25] <@Derick> counting nr,s \ is the only one with a "positive" vote
[17:55:38] <@lsmith> i have added :::
[17:55:46] <@lsmith> http://pastebin.com/m7a69c046
[17:55:58] <@andrei_> ::: is FAIL
[17:56:01] <@andrei_> apparently :)
[17:56:15] <@CelloG> #4 on ::: is probably +1 an IDE would have no trouble with it
[17:56:16] <@lsmith> dmitry: can you check out http://pastebin.com/m7a69c046 ?
[17:56:29] <@Derick> CelloG: but i'd give it a -1 for (1)
[17:56:33] <@CelloG> but -2 on # of characters :)
[17:56:43] <@CelloG> Derick: agreed
[17:56:46] <@lsmith> Derick: number of chars is already in (5)
[17:56:55] <@lsmith> so i did not want to factor the number of chars into (1)
[17:57:00] <@Derick> lsmith: no, I meant ::: vs :: or ::::
[17:57:04] <@andrei_> ::::::
[17:57:11] <@CelloG> ah! make it stop!
[17:57:14] <@CelloG> :)
[17:57:14] <@otherbird> andrei_: ouch
[17:57:15] <@Derick> :)
[17:57:15] <@andrei_> Ok, I think it's clear which way the cookie is crumbling.
[17:57:24] <@dmitry> forget about IDE, we are making language for human
[17:57:35] <@CelloG> dmitry, voice of reason
[17:57:39] <@Derick> humans use IDEs
[17:57:44] <@otherbird> some of them
[17:57:46] <@lsmith> dmitry: like ScottMac said .. not all criterias are weighted evenly
[17:57:47] <@Derick> nobody uses notepad or edlin
[17:57:57] <@andrei_> lsmith, that was me :)
[17:58:09] <@otherbird> Derick: 'nobody'? would you like me to start another poll? :)
[17:58:14] <@johannes_> people using notepad won't use namespace, or it's their problem ...
[17:58:19] <@Derick> otherbird: nobody sane at least
[17:58:19] <@andrei_> ok ok
[17:58:23] <@lsmith> Scotty, Scottdrei, andrei
[17:58:24] <@lsmith> all the same :)
[17:58:25] <@otherbird> shh
[17:58:26] <@andrei_> let's not get into emacs vs. vim
[17:58:27] <@CelloG> johannes_: what do you mean?
[17:58:28] <@Derick> scottdor
[17:58:41] <@andrei_> because we all know who would win :)
[17:58:49] <@Derick> yes, vim
[17:58:50] <@Derick> :)
[17:59:01] * CelloG thinks this is deteriorating fast, let's wrap it up efficiently so I can go eat breakfast
[17:59:06] <@andrei_> me too
[17:59:09] <@andrei_> i'm due for a french toast
[17:59:11] <@Derick> dinner soon
[17:59:15] <@otherbird> who's actually against \?
[17:59:18] <@otherbird> (without the ?)
[17:59:22] <@CelloG> dmitry was
[17:59:24] <@CelloG> I thought?
[17:59:28] <@Derick> yeah
[17:59:32] <@otherbird> and nobody else?
[17:59:52] <@CelloG> johannes_: is there some problem with \ and notepad?
[17:59:59] <@auroraeos> no
[18:00:01] <@otherbird> CelloG: no there isn't
[18:00:05] <@lsmith> lets always count Stas -1 for any proposal .. when we are trying to determine if a proposal has a clear majority
[18:00:14] <@andrei_> hahahaha
[18:00:16] <@auroraeos> LOL
[18:00:19] <@Derick> :)
[18:00:23] <@otherbird> poor Stas :)
[18:00:26] <@lsmith> i am not saying this as a hit on Stas
[18:00:33] <@lsmith> i am just saying that Stas's opinion is important
[18:00:35] <@CelloG> I think that is fair, just because Stas has expressed clear opinions against a new separator
[18:00:36] <@lsmith> and since he is not here
[18:00:46] <@otherbird> ok
[18:01:06] <@dmitry> Stat was for ->
[18:01:14] <@CelloG> right
[18:01:15] <@dmitry> or classes only
[18:01:20] <@Derick> yeah, but also for modifying :: to ->
[18:01:24] <@CelloG> also true
[18:01:24] <@otherbird> 2 against how many? 9?
[18:01:38] <@dmitry> only as an alternative syntax
[18:01:40] <@lsmith> dmitry: but we have accepted that even if Stas was opposed to a new separator, we were unanimous enough to proceed
[18:01:46] <@CelloG> could I suggest we make this whole log publicly accessible?
[18:01:47] * otherbird would still go to classes only at the drop of a hat but if that's not an option..
[18:01:58] <@CelloG> perhaps editing out the jokes/entering/leaving the channel
[18:02:02] <@andrei_> it is an option.
[18:02:11] <@otherbird> CelloG: that was intended, actually I think we should keep the jokes in
[18:02:25] <@lsmith> yeah no need to edit ..
[18:02:39] <@andrei_> let them slog through what we had to go through.
[18:02:41] <@CelloG> ok, no problem here with that, just thought it might make the read a bit shorter
[18:02:55] <@auroraeos> eh, the jokes are cute ;)
[18:03:03] <@lsmith> i will put the pastebin on the wiki somewhere i guess
[18:03:11] <@andrei_> So \ it is.
[18:03:15] <@andrei_> Thank Science.
[18:03:17] <@otherbird> ok
[18:03:42] <@otherbird> and Greg, when it's to a state it can be documented - come and talk to me
[18:03:52] <@CelloG> if that is true, then I would want to make clear how the patch I wrote works.  I leave tomorrow for a week-long residency at Harvard, and am not sure how inet is at the hotel
[18:04:08] <@lsmith> i feel, that even while this was comparitively quick to get to \ (compared to the entire namespace history), that we did it based on the experience we have gained
[18:04:15] <@lsmith> so it does not feel rash or anything
[18:04:21] <@otherbird> lsmith: agreed
[18:04:33] <@otherbird> CelloG: on here, in public space - where?
[18:04:36] <@otherbird> rfc it?
[18:04:39] <@CelloG> first off, there is a clear bug in the patch that I realized when I work up this morning.  CG(current_import) is mistakenly applied to short function names like "bar()"
[18:04:55] <@CelloG> just here, so any questions can be asked (especially from Dmitry)
[18:05:09] <@CelloG> because I'd like it to be helpful, as a base to work from
[18:05:16] <@CelloG> but I don't think it is a final product yet
[18:05:21] <@dmitry> yes you are welcome
[18:05:28] <@otherbird> I don't think anybody assumed it was, Greg
[18:06:03] <@CelloG> zend_resolve_class_name() is used to apply namespace to current function name, but we need a new function, perhaps zend_resolve_non_class_name() to be used for constant/function resolution
[18:06:18] <@CelloG> the idea here is that for constants/functions, we don't want to apply "use" imports directly, only to the namespace part of their name
[18:06:32] <@CelloG> so foo/bar() checks "foo" for import name, but bar() does not check "bar" for import name
[18:06:36] <@CelloG> am I making sense so far?
[18:07:07] <@otherbird> you're asking dmitry or all of us?
[18:07:24] <@CelloG> anyone, but particularly dmitry since he has ZendEngine2 karma
[18:07:30] <@dmitry> I don't hold it in my head I need to look
[18:07:45] <@dmitry> Please ask questions by email
[18:08:01] <@dmitry> I'll answer them on Monday
[18:08:05] <@CelloG> the only other thing to be aware of is that the patch implements relative\ns\name
[18:08:23] <@CelloG> so in the example bar\other\thing() becomes foo\bar\other\thing()
[18:08:46] <@CelloG> this would be relatively simple to change, but touches a lot of unit tests
[18:09:18] <@dmitry> in case you change behavior you can just remove tests
[18:09:24] <@CelloG> otherwise it should be good to go.  I also touched ext/reflection, ext/standard/unserializer.re, and ext/tokenizer
[18:09:28] <@dmitry> I mean old tests
[18:09:37] <@CelloG> in the tests, I just prefix things with \ that need it
[18:09:51] <@CelloG> the patch does *not* change the name resolution of classes, as that is a separate issue
[18:09:52] <@dmitry> it seems ok
[18:10:05] <@andrei_> ok, i'm off to get breakfast
[18:10:24] <@CelloG> to all: http://pear.php.net/~greg/backslash.sep.patch.txt can be applied to PHP 5.3 if you want to play around with \ as separator
[18:10:39] <@CelloG> thanks everyone, this was unbelievably productive
[18:10:50] <@andrei_> it's even better in real-life :)
[18:10:51] <@CelloG> I still can't quite believe a decision was made
[18:11:17] <@CelloG> dmitry: I'll fix that bug I mentioned and update the patch, and send you an email with the details
[18:11:28] <@CelloG> and include Stas as well
[18:11:30] <@dmitry> ok
[18:11:35] <@dmitry> I'll take a look