Re: [PHP-DEV] Namespaces internal refactoring

2016-08-19 Thread Michał Brzuchalski
Hi, As the initiator of this discussion, I would like to summarize it well, but I need this a little more time. Discussion was lively and I would like all the arguments to be included in the summary. It seems to me that I would need this help, and I am eager to progress and evolution of language

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-15 Thread Fleshgrinder
On 8/15/2016 12:11 AM, Stanislav Malyshev wrote: > Hi! > >> - PHP 7 has private classes through anonymous/inner classes. > > It's not exactly the same, and I suspect the same is true for Ruby. It's > true that anonymous classes can not be instantiated by other code. But > that is not what we were

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-15 Thread Lester Caine
On 15/08/16 01:42, guilhermebla...@gmail.com wrote: >>> Annotation parser needs to understand what was "use"d, so it can >>> > > properly refer to FQCN. That way, we need to somehow discover something >> > >> > I see what you mean. This seems to be a problem because you are trying >> > to do compil

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread guilhermebla...@gmail.com
Hi Stas, I'll comment your PS, since I'm the author of the PR. On Sun, Aug 14, 2016 at 6:11 PM, Stanislav Malyshev wrote: > Hi! > > > - PHP 7 has private classes through anonymous/inner classes. > > It's not exactly the same, and I suspect the same is true for Ruby. It's > true that anonymous c

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread guilhermebla...@gmail.com
Hi Stas, On Sun, Aug 14, 2016 at 6:35 PM, Stanislav Malyshev wrote: > Hi! > > > A realization that needs to be made is that beginners would be using > > libraries that requires to make valid restrictions, preventing those > > beginners to mess up with code they shouldn't. So even if the use case

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread Christoph M. Becker
On 15.08.2016 at 00:11, Stanislav Malyshev wrote: > Also, there's a difference IMO between classes and class' properties. > Class details may be - indeed, need to be - hidden because this is what > the class is, one of it's reasons to exist - a tool to reduce complexity > by hiding irrelevant info

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread Marco Pivetta
Hey Stas On 15 Aug 2016 00:35, "Stanislav Malyshev" wrote: > > Hi! > > > A realization that needs to be made is that beginners would be using > > libraries that requires to make valid restrictions, preventing those > > beginners to mess up with code they shouldn't. So even if the use case > > is

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread Stanislav Malyshev
Hi! > A realization that needs to be made is that beginners would be using > libraries that requires to make valid restrictions, preventing those > beginners to mess up with code they shouldn't. So even if the use case > is only valid for 0.01% of code producers, it might be valid for 20%+ of > co

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread Stanislav Malyshev
Hi! > - PHP 7 has private classes through anonymous/inner classes. It's not exactly the same, and I suspect the same is true for Ruby. It's true that anonymous classes can not be instantiated by other code. But that is not what we were discussing here. This particular effect is somewhat similar,

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread guilhermebla...@gmail.com
Hi Stas, Answers inline. On Sun, Aug 14, 2016 at 5:14 AM, Stanislav Malyshev wrote: > Hi! > > > Today I see 2 sides in PHP Internals. One that truly believes that PHP > > should adopt more concepts of object orientation, such as Annotations, > > Generics, Overloading, Class visibility, Collecti

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread Fleshgrinder
On 8/14/2016 11:14 AM, Stanislav Malyshev wrote: > Hi! > >> Today I see 2 sides in PHP Internals. One that truly believes that PHP >> should adopt more concepts of object orientation, such as Annotations, >> Generics, Overloading, Class visibility, Collections, Exceptions, etc > > Object orientat

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread Lester Caine
On 14/08/16 10:14, Stanislav Malyshev wrote: >> > I do have a lengthy, detailed and complex plan of how namespace >> > refactoring could be made, what it would enable feature-wise, and how it > Before getting to the question of how, we need to pass the question of > why. And that I think is much m

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-14 Thread Stanislav Malyshev
Hi! > Today I see 2 sides in PHP Internals. One that truly believes that PHP > should adopt more concepts of object orientation, such as Annotations, > Generics, Overloading, Class visibility, Collections, Exceptions, etc Object orientation is a very broad term. You can be very well object orient

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-13 Thread guilhermebla...@gmail.com
Hi Stas, I'll answer your message as it directly refers to links with my name. I understand the reasons of why namespaces were implemented that way, as I follow this list for quite a long time. I never complained about the implementation itself as it was publicly introduced originally back in Augu

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-13 Thread Stanislav Malyshev
Hi! > The current approach to namespaces blocks new features like you see it > in the following PR. The link already points to the two most relevant > comments that should give you full context: > > https://github.com/php/php-src/pull/947/#issuecomment-224912697 I don't think this - private clas

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-10 Thread Fleshgrinder
The current approach to namespaces blocks new features like you see it in the following PR. The link already points to the two most relevant comments that should give you full context: https://github.com/php/php-src/pull/947/#issuecomment-224912697 You might know other approaches to solve this. W

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-10 Thread Stanislav Malyshev
Hi! > It is. > > I agree with your thoughts. > Back in 2008, namespaces were designed and added to PHP 5.3 as just > substrings in class names. That is correct (except that namespaces first appeared in 2007, first commit f32ffe9b430b718628f868e449c1fcbdc8ec9ef6 if you're interested, of course we

Re: [PHP-DEV] Namespaces internal refactoring

2016-08-09 Thread Julien Pauli
On Mon, Aug 8, 2016 at 1:08 PM, Michał Brzuchalski wrote: > Hi internals, > > I would like to present my idea for namespaces refactoring and provide an > RFC for them. > > Currently in PHP namespaces are implemented as a prefix of class or > function name. Using ReflectionClass or ReflectionFuncti

[PHP-DEV] Namespaces internal refactoring

2016-08-08 Thread Michał Brzuchalski
Hi internals, I would like to present my idea for namespaces refactoring and provide an RFC for them. Currently in PHP namespaces are implemented as a prefix of class or function name. Using ReflectionClass or ReflectionFunction we can retrieve class/function name and its namespace-name. In both