Re: [PHP-DEV] "Namespaces in bundled extensions" and iterable additions to the standard library

On 02/06/2021 02:30, tyson andre wrote: - Did anyone have feedback on whether iterable\ or Iterable\ makes more sense - Personally, iterable\ seems like it should be an exception due to it also being used as a soft reserved keyword that is typically lowercase. To me, a lower-case namespace

[PHP-DEV] "Namespaces in bundled extensions" and iterable additions to the standard library

Hi internals, Recently, there have been 3 proposals to add functionality related to iterables/iterators to the standard library where voting was postponed for reasons related to namespacing policy: 1. https://wiki.php.net/rfc/any_all_on_iterable - where major objections were not having enough

Re: [PHP-DEV] Namespaces in Core

On Tue, Feb 7, 2017 at 6:59 PM, Dan Ackroyd wrote: > On 7 February 2017 at 17:56, Scott Arciszewski wrote: >> I'm taking all the No votes spawned by this thread to mean "we >> don't want namespaced functions ever". > > That would be a bad assumption.

Re: [PHP-DEV] Namespaces in Core

On 7 February 2017 at 17:56, Scott Arciszewski wrote: > I'm taking all the No votes spawned by this thread to mean "we > don't want namespaced functions ever". That would be a bad assumption. Peter Cowburn wrote: > Slinking in a vote which essentially is about adopting >

Re: [PHP-DEV] Namespaces in Core

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder wrote: > Hey guys! :) > > First: I like namespaces in Core but here me out! > > https://wiki.php.net/rfc/libsodium > > The second vote is clearly going to be that this new feature is added to > the core with a namespace. I

Re: [PHP-DEV] Namespaces in Core

On 2/7/2017 11:39 AM, Niklas Keller wrote: > I don't see this as a potential problem. Autoloadeds are (1) not triggered > for already loaded symbols and (2) and more importantly, autoloaders > usually use a list of prefixes to load, so a whitelist, not a blacklist. > > Regards, Niklas > This is

Re: [PHP-DEV] Namespaces in Core

There will be breaking changes for the sodium users anyways since some functions will not be included and the complete error handling needs to be changed from errors to exceptions. -- Richard "Fleshgrinder" Fussenegger -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] Namespaces in Core

On Tue, Feb 7, 2017 at 12:00 PM, Derick Rethans wrote: > On Mon, 6 Feb 2017, Nikita Popov wrote: > > > On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder > wrote: > > > > > First: I like namespaces in Core but here me out! > > > > > I'm strongly against use of

Re: [PHP-DEV] Namespaces in Core

On Mon, 6 Feb 2017, Stanislav Malyshev wrote: > > I'm strongly against use of the PHP namespace as a blanket namespace > > for bundled PHP extensions. The PHP namespace should be used only > > for functionality that is actually in some way related to PHP. For > > example, the php-ast extension

Re: [PHP-DEV] Namespaces in Core

On Mon, 6 Feb 2017, Sara Golemon wrote: > On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov wrote: > > > I'm strongly against use of the PHP namespace as a blanket namespace > > for bundled PHP extensions. The PHP namespace should be used only > > for functionality that is

Re: [PHP-DEV] Namespaces in Core

On Mon, 6 Feb 2017, Nikita Popov wrote: > On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder wrote: > > > First: I like namespaces in Core but here me out! > I'm strongly against use of the PHP namespace as a blanket namespace for > bundled PHP extensions. The PHP namespace

Re: [PHP-DEV] Namespaces in Core

> > I thought about this too. I hope you understood that the main reasoning > for me to choose a well known namespace prefix is related to > auto-loading and when to trigger it. The lack of function and constant > auto-loading is a pain and having well known prefixes could solve the > issue since

Re: [PHP-DEV] Namespaces in Core

"Stanislav Malyshev" wrote in message news:a8d24d41-bd3a-0881-3fcb-9366fe974...@gmail.com... Hi! New classes within 7.2 (e.g. \HashContext) to be moved without concern for BC (e.g. \php\Hash\HashContext) Older classes (e.g. \RecursiveIteratorIterator) to be moved AND ALIASED FOR BC (e.g.

Re: [PHP-DEV] Namespaces in Core

"Fleshgrinder" wrote in message news:04295b76-3e0d-5ea3-7b4e-d07a15db4...@fleshgrinder.com... On 2/6/2017 9:47 PM, Nikita Popov wrote: I'm strongly against use of the PHP namespace as a blanket namespace for bundled PHP extensions. The PHP namespace should be used only for functionality that

Re: [PHP-DEV] Namespaces in Core

On 07/02/17 08:53, Rowan Collins wrote: >> I think the Sodium RFC vote is not about namespace but rather about >> breaking everything which already use the pecl extension. > Well, it's about both, that's why it's a hard question: in order not to break > existing use of the extension, we need to

Re: [PHP-DEV] Namespaces in Core

Just my two cents, but moving and aliasing core PHP classes/interfaces/functions sounds like an absolutely horrible idea. My biggest question is WHY would you do that? Writing user-space code today that uses the global namespace would be considered extremely bad practice - no one should do that.

Re: [PHP-DEV] Namespaces in Core

On 7 February 2017 06:52:32 GMT+00:00, Remi Collet wrote: >> https://wiki.php.net/rfc/libsodium > >I think the Sodium RFC vote is not about namespace but rather about >breaking everything which already use the pecl extension. Well, it's about both, that's why it's a hard

Re: [PHP-DEV] Namespaces in Core

Le 06/02/2017 à 18:21, Fleshgrinder a écrit : > Hey guys! :) > > First: I like namespaces in Core but here me out! > > https://wiki.php.net/rfc/libsodium I think the Sodium RFC vote is not about namespace but rather about breaking everything which already use the pecl extension. This extension

Re: [PHP-DEV] Namespaces in Core

Hi! > New classes within 7.2 (e.g. \HashContext) to be moved without concern > for BC (e.g. \php\Hash\HashContext) > > Older classes (e.g. \RecursiveIteratorIterator) to be moved AND > ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator) Do we really need this? I mean, it's not

Re: [PHP-DEV] Namespaces in Core

Hi! > I'm strongly against use of the PHP namespace as a blanket namespace for > bundled PHP extensions. The PHP namespace should be used only for > functionality that is actually in some way related to PHP. For example, the > php-ast extension could reasonably be namespaced as php\ast, as it

Re: [PHP-DEV] Namespaces in Core

On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov wrote: > I'm strongly against use of the PHP namespace as a blanket namespace for > bundled PHP extensions. The PHP namespace should be used only for > functionality that is actually in some way related to PHP. For example, the >

Re: [PHP-DEV] Namespaces in Core

Idea with PHP prefix is quite interesting, but as Nikita said only for PHP related features. There is one missing thing in those proposals. Let's make PHP great again! Let it be `PHP\` prefix :) To be camel or not to be? - solved! 2017-02-06 22:01 GMT+01:00 Fleshgrinder :

Re: [PHP-DEV] Namespaces in Core

On 2/6/2017 9:47 PM, Nikita Popov wrote: > I'm strongly against use of the PHP namespace as a blanket namespace > for bundled PHP extensions. The PHP namespace should be used only > for functionality that is actually in some way related to PHP. For > example, the php-ast extension could

Re: [PHP-DEV] Namespaces in Core

On 2/6/2017 9:27 PM, Sara Golemon wrote: > I've been having this same thought lately since looking at the sodium > RFC. Here are my thoughts, centered on the goal of having classes > (and maybe functions?) in a \php\{extname}\ namespace hierarchy. > > New classes within 7.2 (e.g. \HashContext)

Re: [PHP-DEV] Namespaces in Core

On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder wrote: > Hey guys! :) > > First: I like namespaces in Core but here me out! > > https://wiki.php.net/rfc/libsodium > > The second vote is clearly going to be that this new feature is added to > the core with a namespace. I

Re: [PHP-DEV] Namespaces in Core

> On Feb 6, 2017, at 13:50, Peter Cowburn wrote: > > a vote which essentially is about adopting > namespaces in core, via new library RFC, is not the way to go about > changing our coding standards. In short, I don't want to the see the > situation where this extension

Re: [PHP-DEV] Namespaces in Core

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder wrote: > First: I like namespaces in Core but here me out! > > The PHP (case does not matter) would be the proper vendor name to put > Core stuff in, as far as I remember it is also reserved for PHP > functionality. There were

Re: [PHP-DEV] Namespaces in Core

On 6 February 2017 at 17:21, Fleshgrinder wrote: > Hey guys! :) > > First: I like namespaces in Core but here me out! > > https://wiki.php.net/rfc/libsodium > > The second vote is clearly going to be that this new feature is added to > the core with a namespace. I already

[PHP-DEV] Namespaces in Core

Hey guys! :) First: I like namespaces in Core but here me out! https://wiki.php.net/rfc/libsodium The second vote is clearly going to be that this new feature is added to the core with a namespace. I already complained about this but it seems to go unnoticed or others do not see the potential

Re: [PHP-DEV] Namespaces internal refactoring

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

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

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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 >

Re: [PHP-DEV] Namespaces internal refactoring

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.

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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 >

Re: [PHP-DEV] Namespaces internal refactoring

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

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,

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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.

Re: [PHP-DEV] Namespaces internal refactoring

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

Re: [PHP-DEV] Namespaces internal refactoring

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

[PHP-DEV] Namespaces internal refactoring

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

[PHP-DEV] Namespaces

Hi, It has been brought to my attention that my consistent use of \ prefixing of global functions is an eyesore, but I've got a simple little PoC that shows why I do it, and now I'm wondering if the behavior I'm working around should qualify as a PHP bug? https://3v4l.org/po925 Scott

Re: [PHP-DEV] Namespaces

Scott, On Fri, Dec 4, 2015 at 11:26 AM, Scott Arciszewski wrote: > Hi, > > It has been brought to my attention that my consistent use of \ prefixing > of global functions is an eyesore, but I've got a simple little PoC that > shows why I do it, and now I'm wondering if the

Re: [PHP-DEV] Namespaces

Stanislav, Anthony: Okay, I just wanted to make sure I wasn't overlooking an unintended behavior. I'm going to continue using \explicit_prefixing(). http://userjac.com/wp-content/uploads/2014/05/haters-gonna-hate-cool-dog.jpg Scott Arciszewski Chief Development Officer Paragon Initiative

Re: [PHP-DEV] Namespaces

Hi! > It has been brought to my attention that my consistent use of \ prefixing > of global functions is an eyesore, but I've got a simple little PoC that > shows why I do it, and now I'm wondering if the behavior I'm working around > should qualify as a PHP bug? No, it's not a bug, it is a

Re: [PHP-DEV] Namespaces and \t, \r, \n, \0 etc.

Hi Johannes, Johannes Schlüter schrieb: to me it does not seem to make sense to use tabs or linefeeds (or whatever other strange escaped characters) in namespace'd names. So I'd suggest generating a fatal error when somebody uses them. \n is no newline (yes \n is, \n not ...) - no need for

Re: [PHP-DEV] Namespaces and \t, \r, \n, \0 etc.

Hello Stefan, If the engine fails to lookup a class and detected a namespace separator we could actually add this check as well and suggest it as a probable cause of the error. marcus Tuesday, October 28, 2008, 1:49:00 PM, you wrote: Hi Johannes, Johannes Schlüter schrieb: to me it does

Re: [PHP-DEV] Namespaces and \t, \r, \n, \0 etc.

What about just silently converting newline to '\n' and tab to '\t', etc. I mean if you cant put those characters in a string, who will notice? or better, just use a single-quoted string. Regards, Josh On Wed, Oct 29, 2008 at 1:28 AM, Marcus Boerger [EMAIL PROTECTED] wrote: Hello Stefan, If

Re: [PHP-DEV] Namespaces and \t, \r, \n, \0 etc.

On Tue, Oct 28, 2008 at 2:30 PM, Josh [EMAIL PROTECTED] wrote: What about just silently converting newline to '\n' and tab to '\t', etc. I mean if you cant put those characters in a string, who will notice? or better, just use a single-quoted string. Random programmer here, but I really

[PHP-DEV] Namespaces and \t, \r, \n, \0 etc.

Hi list, to me it does not seem to make sense to use tabs or linefeeds (or whatever other strange escaped characters) in namespace'd names. So I'd suggest generating a fatal error when somebody uses them. Regards, Stefan -- e-novative - We make IT work for you. http://www.e-novative.de

Re: [PHP-DEV] Namespaces and \t, \r, \n, \0 etc.

On Mon, 2008-10-27 at 10:02 +0100, Stefan Priebsch wrote: Hi list, to me it does not seem to make sense to use tabs or linefeeds (or whatever other strange escaped characters) in namespace'd names. So I'd suggest generating a fatal error when somebody uses them. \n is no newline (yes \n is,

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

On Thu, Oct 16, 2008 at 05:23, Gregory Beaver [EMAIL PROTECTED] wrote: Hi again, I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section Can we please start small and then incrementally add more

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

Hannes Magnusson wrote: I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section Can we please start small and then incrementally add more features? Lets start with classes only in namespaces in 5.3. The

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

On Thu, Oct 16, 2008 at 08:54, Lester Caine [EMAIL PROTECTED] wrote: Hannes Magnusson wrote: I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section Can we please start small and then incrementally add

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

Hannes, Lester... Can we please start small and then incrementally add more features? Lets start with classes only in namespaces in 5.3. The problem with that statement is that if it is used to ignore the other problems, then at some point it may be necessary to re-write all the new namespace

Re: [PHP-DEV] namespaces and alpha3

Hi! What would happen if we give the namespace implementation a chance to mature is that it can be delivered as a fully-fledged language element rather than a partially-fledged and potentially flawed one. What do you mean by chance to mature? Only chance for it to mature is people actually

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

I vote for option 3. http://wiki.php.net/rfc/namespaceissues Seems like the best fit all around. Steph Fox wrote: Hannes, Lester... Can we please start small and then incrementally add more features? Lets start with classes only in namespaces in 5.3. The problem with that statement is

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

The thread where your vote has to go is: [PHP-DEV] my last attempt at sanity with namespaces started also by Gregory. On Thu, Oct 16, 2008 at 5:30 PM, Justin Carlson [EMAIL PROTECTED]wrote: I vote for option 3. http://wiki.php.net/rfc/namespaceissues Seems like the best fit all around.

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

Hi! Gregory Beaver wrote: Hi again, I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section to the RFC that does so: http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

Hi! The problem with that statement is that if it is used to ignore the other problems, then at some point it may be necessary to re-write all the new namespace code simply to allow additional features to be added! So? We rewrote pretty much every other part of PHP - engine, object model,

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas'sproposal doesn't work

Stanislav Malyshev wrote: Hi! The problem with that statement is that if it is used to ignore the other problems, then at some point it may be necessary to re-write all the new namespace code simply to allow additional features to be added! So? We rewrote pretty much every other part of

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

Since this got cut without am answer I'll repeat it since *I* would still like to know the answer! Lester Caine wrote: So 'USE' ? I'm I understanding things right on this one that one would 'define' the namespace in one sort of header file, and then add the use namespace to those files that

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas'sproposal doesn't work

Hi! My point is that for this code: ?php Classname::Method(); ? The proposal does not solve the name conflict. If no one rewrites their Right, it does not. So doesn't yours - you need to modify the code in both cases. code to use Classname-Method(), then no one will be protected from

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas'sproposal doesn't work

Stanislav Malyshev wrote: Hi! My point is that for this code: ?php Classname::Method(); ? The proposal does not solve the name conflict. If no one rewrites their Right, it does not. So doesn't yours - you need to modify the code in both cases. the solution I proposed emits an

Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas'sproposal doesn't work

Hi! ?php Classname::Method(); ? The proposal does not solve the name conflict. If no one rewrites their Right, it does not. So doesn't yours - you need to modify the code in both cases. the solution I proposed emits an E_WARNING on the conflict. You proposed a number of solutions,

Re: [PHP-DEV] namespaces and alpha3

On Fri, 10 Oct 2008, Lukas Kahwe Smith wrote: At this point I guess we have the choice between: 1) rip them out 2) status quo 3) Stas proposal 4) Dmitrys proposal Again I hope that Stas/Dmitry will give us an insight about their proposals, though Stas proposal might or might not see

Re: [PHP-DEV] namespaces and alpha3

Ron Rademaker wrote: Lester Caine wrote: Derick Rethans wrote: On Fri, 10 Oct 2008, Lukas Kahwe Smith wrote: At this point I guess we have the choice between: 1) rip them out 2) status quo 3) Stas proposal 4) Dmitrys proposal Again I hope that Stas/Dmitry will give us an insight about

Re: [PHP-DEV] namespaces and alpha3

Am 15.10.2008 um 09:04 schrieb Derick Rethans: As we're getting really close to 5.3, I would suggest to remove namespaces from this release as we're simply not done with even agreeing on how things should work. PHP 5.3 has many other cool things, and leaving namespaces for PHP 6 means we're

Re: [PHP-DEV] namespaces and alpha3

Thats awesome. By the way, what is it? I haven't had the chance of following the hundreds of namespaces threads with thousands of replies. All I have gather so far is a massive amount of FUD. Could someone summarize what you are trying to convince Greg to agree on? I would greatly

Re: [PHP-DEV] namespaces and alpha3

Hi. Steph Fox wrote: Not trying to undo it, just trying to prevent a horrible mistake being made under pressure. What happened to release when it is ready? Who puts up that pressure? And why is there more pressure for 5.3 to be released than to release things that people have been hoping

Re: [PHP-DEV] namespaces and alpha3

Hi. Steph Fox wrote: Surely everyone can see the very public ongoing discussions on internals@ over the course of this and last year? Sure. No? There's a very big difference between 'testing' and 'preparing to migrate a codebase'. Ok, but the broad testing needs a broad scope. We need

Re: [PHP-DEV] namespaces and alpha3

Hi. Stanislav Malyshev wrote: This is what I've be fearing. First slated for 5.0. Then 5.3. Now 6.0. It appears there's consensus to rip it out which, in my prior post, I was all for if people felt it meant getting it right. If 5.3 is not going to have namespaces, we will remove it's use

Re: [PHP-DEV] namespaces and alpha3

Hi Elizabeth, This can be solved in three ways. 1. Greg's leaf solution foo::bar-baz(); - namespace foo::bar, function baz foo-bar::baz(); - namespace foo, static method bar::baz Personally I don't like this, get confusing even if we pick some weird operator like : 2. Don't allow

Re: [PHP-DEV] namespaces and alpha3

Hi. Sorry, I just have to make some points now. Call it venting for a cause, if you think I overreact. But be sure that the consequences I lay out below for TYPO3v5 and FLOW3 are very real. Vesselin Kenashkov wrote: I see the point and objections against quick and dirty, but on the other

Re: [PHP-DEV] namespaces and alpha3

Hi! This can be solved in three ways. Somehow you did not mention my idea of using foo::bar-baz() for method call. Was it because you don't like it? If so, why? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] --

Re: [PHP-DEV] namespaces and alpha3

Hi! It seems that we're not quite 100% how we want to do things. Reading the Namespaces with functions/constants part of Stas' RFC makes me cringe... just changing the behavior of - and :: to just make things work is a cludge, and a bad one at that. The other part, Namespaces I think

Re: [PHP-DEV] namespaces and alpha3

Hi! My thoughts exactly. I realize it's a bold move, but it's a much better alternative than the fuzz about an implementation that doesn't work, or is incomplete, or needs to be broken in the future to add new stuff. Of course, if we have no implementation this means it is complete, not

Re: [PHP-DEV] namespaces and alpha3

On 15.10.2008, at 11:35, Ron Rademaker wrote: Lester Caine wrote: What would be the advantage of wrapping legacy functions in a namespace over wrapping them into a class as static functions? THAT is probably why I am asking the question? And may well be key to my understanding why

Re: [PHP-DEV] namespaces - my RFC

Hi, My proposals are here: http://wiki.php.net/rfc/namespaceref Just for the record: I like both of them, the second one would probably be better to accomodate those who want functions in namespaces. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] namespaces and alpha3

Lester Caine wrote: What would be the advantage of wrapping legacy functions in a namespace over wrapping them into a class as static functions? THAT is probably why I am asking the question? And may well be key to my understanding why converting non OO code into OO code in PHP is so

Re: [PHP-DEV] namespaces and alpha3

On 15 Oct 2008, at 09:04, Derick Rethans wrote: However, a third one might be to use a syntax separator that we've not seen at all yet (I'd say ':::'). FWIW, this is my +0.5 (with +1 being dropping). I'm absolutely against reusing a selector for this. -- Geoffrey Sneddon

Re: [PHP-DEV] namespaces and alpha3

On Wed, Oct 15, 2008 at 00:30, Andi Gutmans [EMAIL PROTECTED] wrote: -Original Message- From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2008 2:15 PM To: Steph Fox Cc: Stas Malyshev; PHP internals Subject: Re: [PHP-DEV] namespaces and alpha3 err .. you

Re: [PHP-DEV] namespaces and alpha3

Lukas Kahwe Smith wrote: On 15.10.2008, at 11:35, Ron Rademaker wrote: Lester Caine wrote: What would be the advantage of wrapping legacy functions in a namespace over wrapping them into a class as static functions? THAT is probably why I am asking the question? And may well be key to

Re: [PHP-DEV] namespaces and alpha3

Elizabeth M Smith wrote: snip This can be solved in three ways. 1. Greg's leaf solution foo::bar-baz(); - namespace foo::bar, function baz foo-bar::baz(); - namespace foo, static method bar::baz Personally I don't like this, get confusing even if we pick some weird operator like : 2.

Re: [PHP-DEV] namespaces and alpha3

If all issues are evolved to reusing same operator, :: ... Why is it so complicated to change the separator and get everything supported? Is that too hard? +3 for Liz option #3. Long live :::! []s, On Wed, Oct 15, 2008 at 4:41 PM, Ryan Panning [EMAIL PROTECTED] wrote: Elizabeth M Smith wrote:

Re: [PHP-DEV] namespaces and alpha3

Derick Rethans wrote: On Fri, 10 Oct 2008, Lukas Kahwe Smith wrote: At this point I guess we have the choice between: 1) rip them out 2) status quo 3) Stas proposal 4) Dmitrys proposal Again I hope that Stas/Dmitry will give us an insight about their proposals, though Stas proposal might or

Re: [PHP-DEV] namespaces and alpha3

On Wednesday 15 October 2008 11:16:09 Lester Caine wrote: THAT is probably why I am asking the question? And may well be key to my understanding why converting non OO code into OO code in PHP is so problematic. When I was coding in CC++ more heavily libraries did not need to be objects and the

Re: [PHP-DEV] namespaces and alpha3

On Wed, Oct 15, 2008 at 3:49 PM, Guilherme Blanco [EMAIL PROTECTED] wrote: If all issues are evolved to reusing same operator, :: ... Why is it so complicated to change the separator and get everything supported? Is that too hard? +3 for Liz option #3. Long live :::! []s, On Wed, Oct

Re: [PHP-DEV] namespaces and alpha3

2008/10/15 Diego Feitosa [EMAIL PROTECTED]: snip Or even use my::cool::namespace#GregsNamespaceElement Because # is a comment, other solutions for unused operators is a better choice IF the double colon operator has to be changed in namespaces. I couldn't understand why Greg's proposal

[PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

Hi again, I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section to the RFC that does so: http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work Thanks, Greg -- PHP Internals -

Re: [PHP-DEV] namespaces and alpha3

On 10.10.2008, at 19:02, Stanislav Malyshev wrote: It should be noted that this proposal builds on Stas previous proposal after Zendcon 1. Allow braces for namespaces. So, the syntax for namespaces will be: a) namespace foo; should be first (non-comment) statement in the file, namespace

Re: [PHP-DEV] namespaces and alpha3

On Fri, Oct 10, 2008 at 5:56 PM, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 10 Oct 2008, at 06:03, Lukas Kahwe Smith wrote: 1) rip them out I'm +1 on this. We simply don't have consensus, and I don't see anyway we can have consensus by the time 5.3 has to be frozen. Once namespaces

Re: [PHP-DEV] namespaces and alpha3

Hi Lukas, Just for the record, I was suggesting to add the E_STRICT in PHP6, not in PHP 5.3. I'd missed that, but it doesn't make a whole lot of difference IMHO. The reuse of an existing symbol is going to bring problems, and if we do it now we'll be blocking the possibility of a better

  1   2   3   >