Re: [PHP-DEV] Package php binaries + php script into one single executable file
Hi Olivier, Could you be a little more specific about what questions you have? Is it to do with the licensing or physically how to go about achieving your aim? Regards, James -- James Butler Sent from my iPhone On 15 Mar 2011, at 20:02, "Olivier Hoareau" wrote: > Hi ! > > I would like to be able to "distribute" (freely) a single executable > (binary) containing : > > - php binaries (v 5.3+) > - a php script already packaged as a .phar (1 Mb, requiring PHP 5.3+) > - additional (optional) compiled extensions > - php.ini > - all other resources required by the php executable to run > > The aim is to be able to provide a command line tool based on PHP but not > requiring my user to install PHP *before* using the tool (and only download > the tool as a single executable file to execute it) > I would like my users to be able to use this "packaged" tool (requiring PHP > 5.3+) whatever version of PHP my users have already installed (or not) on > their system. > > Targeted platforms are : > > - windows (XP / Vista / 7) => 70% of my users > - linux debian-like (ubuntu / debian) => 20% of my users > - other platforms => 10% of my users > > At this point, this is not a problem for me to have a huge self-executable > file (> 10Mb). > I need to be able to package a version of the tool using a batch (or > script), as I am using continuous integration. > > Do you have ideas on how to reach this goal ? > The tool is open source, using New BSD License (currently, in beta version). > > Thanks for your answers ! > > Best regards, > > Olivier Hoareau -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Access Modifiers
>> Proposal (after five minutes of thought) >> >> >> 1. Public - A class can be instantiated or called statically from >> anywhere. For reasons of backward compatibility a class without any modifier >> would be considered public. >> >> 2. Internal - A class can only be instantiated/called from within the >> same root namespace. If I have a class Core\Mvc\View, only from within a >> class sharing the same root namespace (ex: Core\Html\Textbox) would I be >> able to access the "View" class. >> >> 3. Private - A class can only be instantiated/called from within the >> exact same namespace. Example, class Core\Mvc\View could only be accessed >> from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller). >> >> What do people think? I'm not too concerned with the exact three I listed >> above, but more and more I think it would be wise if there were a way to >> restrict the accessibility of classes between namespaces. >> >> Jarrod Nettles >> Really like the general idea and think (IMHO) its RFC worthy, but have a few questions... Would there be any method of overriding the the visibility in a child class?And would the child class inherit the parents visibility? I realise this may seem daft initially but I can think of some instances where this might be useful. James -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file streams & metadata
** On 08/03/11 15:46, Matthew Weier O'Phinney wrote: > On 2011-03-08, Pierre Joye wrote: >> On Mon, Mar 7, 2011 at 10:49 PM, Ferenc Kovacs wrote: >> >>> From the sideline: >>> it's hard to belive that there are no one else with opinion on this matter. >>> I don't want to take sides because I don't have the necessary knowledge >>> about the matter, but maybe it would be a good idea to write an RFC, and and >>> maybe a POC, so we can see how intrusive would be the implementation. >>> and if there are more bystanders, then please make your voice heard. >>> Tyrael >> It is very easy to implement what Stas is asking. But that's not the >> question. The question is should we do it? And my point is that we >> should not do it like that, bad design, incomplete and limited >> support. > As a developer, in many cases I'd prefer something incomplete and limited in > support to nothing at all. I've been bitten by the same issue Stas describes, > and having a way to tie into touch and chmod in my stream wrappers would be > incredibly useful -- even if it won't work with _every_ stream. > /while I'd love to have a lovely fully working on all streams-types/platforms solution to make life easy, just having something in place would reduce the pain/workarounds i (and probably others) are having to use to a degree, and gives a starting point for future development. As long as whatever comes out is incomplete rather than broken/buggy then i can't see the problem with not waiting for a fully complete solution. "//A journey/ of a thousand miles begins with a /single step" + "Rome was not built in a day" That said i'm not really sure there is any obvious way to attack the shear number of FS/OS combo's that i've seen in existence... /// -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Module unload
Are you using PHP as a module inside a web server such as apache? If so then module unloading is generally the problem of the web server rather than PHP. Is (fast) cgi not an option? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
As a 'grown up' you should never expect changes to a system to just work without testing, any change introduces risk, you need to mitigate against that risk by testing. Irrespective of whatever the php release notes say (you did read them didn't you), one should run the new version against your code in a non-production environment so all the breakages you experience get trapped and fixed before they hit your users. In a small attempt to steer this back on topic, Does anyone have any problems with python's or gento's enhancement proposals generally? I think they could be made a bit more lightweight but otherwise are pretty useful and transparent. -- James Butler Sent from my iPhone > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC - MACRO
-Original Message-
> From: Mathias Grimm [mailto:mathiasgr...@gmail.com]
> People always will want more, but some features are nice.
> for C/C++ programmers, macro is on of the best things to make thing work
> every where.
>
> its possible to create a IDE macro, but the native php feature will be good.
> template engines can de wrap this functionality too.
> is just like a variable:
>
> $method = $_GET['m'];
> $control = $_GET['c'];
>
> $c = new $control;
> $c->$method();
>
> like a macro..
>
> program is make thing dynamic.
>
> while($object = $iterator->next()) {
>
> }
>
> macro("ITER","while($object = $iterator->next())")
>
> ITER($iterator) {
>$object->save();
> }
>From a userland perspective this looks very un-PHP and potentially hugely
>confusing when new people come across it. Also what scope would these things
>exist at? global scope macro's sound like evil waiting to happen
What you are doing looks to be just slightly re-inventing the wheel for very
little gain. If you are copy and pasting code 'DRY violation' then you probably
need to rethink your code and/or make a new class/function of some sort.
Unless i'm missing something?
On Wed, Dec 22, 2010 at 7:08 PM, Scott MacVicar wrote:
> I really dislike this, what about resolving orders, then people will want
> undef, then ifdef with conditions.
>
> The language doesn't need to introduce anything that makes it more complex
> to use.
>
> - Scott
>
> On 22 Dec 2010, at 11:55, Mathias Grimm wrote:
>
> > I Just want a simple replace-on-the-air to avoid spend time writing more.
> >
> >
> > On Wed, Dec 22, 2010 at 5:43 PM, Stas Malyshev >wrote:
> >
> >> Hi!
> >>
> >>
> >> I want to request a C/C++ feature that i think is good.
> >>>
> >>> MACRO
> >>>
> >>
> >> You know that you could write:
> >> >> #define PF private function
> >> #define SCOPE_CLASS(x) class MyProject_ ## x
> >>
> >>
> >> class UseMacro
> >> {
> >> PF preSave($object)
> >> {
> >> //...
> >> }
> >>
> >> }
> >>
> >> SCOPE_CLASS(Internal)
> >> {
> >>
> >> }
> >>
> >> And then run it through CPP (gcc -Mcpp -E - - < in.php > out.php) and
> get
> >> all the macros processed?
> >> --
> >> Stanislav Malyshev, Software Architect
> >> SugarCRM: http://www.sugarcrm.com/
> >> (408)454-6900 ext. 227
> >>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Add option to disable POST data processing
> -Original Message- > From: Daniel Convissor [mailto:dani...@analysisandsolutions.com] > > Hi James: > > On Sat, Dec 18, 2010 at 05:08:38PM +, James Butler wrote: >> What about people on shared hosting? > > One option may be to put a in an .htaccess file. My thought is that though this is best left to web server in the grand scheme of not making the world too ugly, seeing as people on shared hosts can't change many server settings (if any) but probably can use .htaccess, this would be giving them access to potentially useful feature which those on VPS/dedicated hosts don't need to worry about as we can play with server settings. > Oh, and keep in mind . Apologies, laziness getting the better of me :-) > > --Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
Fiddle, hadn't thought that out. Seeing as it's a non starter for shared hosting, then yes, it should probably be left to the web server to decide. -- James Butler Sent from my iPhone On 18 Dec 2010, at 17:21, "Reindl Harald" wrote: > They can not configure php too or the webserver allows > this for virtuals hosts (IIS afaik does) but on > shared hosting this had to be done from the admin > > I agree that php is the wrong place > > If any compnent have to say "405 Method Not Allowed" > it is the webserver long before starting the interpreter > > Am 18.12.2010 18:08, schrieb James Butler: >> What about people on shared hosting? >> >> -- >> James Butler >> Sent from my iPhone >> >> On 18 Dec 2010, at 17:07, "Daniel Convissor" >> wrote: >> >>> Hi Pierre: >>> >>> On Thu, Dec 16, 2010 at 01:32:15PM +0100, Pierre Joye wrote: >>> >>>> However I would >>>> prefer to bring back a proposal we had a couple of years ago, to >>>> totally disable post data. >>> >>> Completely disabling POST is something that is probably best done >>> via web server configurations. Doing this at the >>> applicaiton/programming layer seems like a kludge. >>> >>> --Dan >>> >>> -- >>> T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y >>> data intensive web and database programming >>> http://www.AnalysisAndSolutions.com/ >>> 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
What about people on shared hosting? -- James Butler Sent from my iPhone On 18 Dec 2010, at 17:07, "Daniel Convissor" wrote: > Hi Pierre: > > On Thu, Dec 16, 2010 at 01:32:15PM +0100, Pierre Joye wrote: > >> However I would >> prefer to bring back a proposal we had a couple of years ago, to >> totally disable post data. > > Completely disabling POST is something that is probably best done > via web server configurations. Doing this at the > applicaiton/programming layer seems like a kludge. > > --Dan > > -- > T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y >data intensive web and database programming >http://www.AnalysisAndSolutions.com/ > 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Performance in Apache: Multi-Process vs Multi-Threaded
This is just personal experience and observation but... We are running Apache Worker with PHP safely by using PHP-FPM rather than via a shared object, so we don't have to worry about thread safety in the PHP component but can have apache multithreaded. I realise this isn't actually multi-threaded PHP but multi-process instead but s means we don't have to worry about making sure extensions etc are thread safe. I haven't got the benchmarks to hand but I might able to dig some of them out if you would like. Apache Worker + FPM was definitely faster when using some simple PHP scripts to test against. Oddly we haven't noticed such a speed increase when benchmarking a Zend Framework based app, but that might be down to application oddities rather than anything else (more work/investigation needed here!). Hope this is helpful. James -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
In short: Globals can be bad, but not always, it depends on the situation PHP is about getting stuff done... It gives developers the rope, if they want to hang themselves thats up to them. If PHP was designed tomorrow, it might not have globals. but it does, they are in use and removing them because some people abuse them is not a good enough reason considering the damage it will cause to lots of perfectly ok designed and thought up code. If it aint broken, don't fix it! Globals aren't that broken, and if you use a framework its not a issue anyway.. This is turning into a GOTO-esque argument... -Original Message- From: Pierre Joye [mailto:pierre@gmail.com] Sent: 09 December 2010 16:59 To: Andrey Hristov Cc: PHP Internals List Subject: Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only On Thu, Dec 9, 2010 at 5:58 PM, Pierre Joye wrote: > On Thu, Dec 9, 2010 at 5:55 PM, Andrey Hristov wrote: > >> If all your functions take 15 params I am worried that your program design >> is flawed, sorry. > > but that's a reason +not :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
-Original Message- From: Ilia Alshanetsky [mailto:i...@prohost.org] On Thu, Dec 9, 2010 at 5:14 AM, Andrey Hristov wrote: > Hi guys, > the topic says most of it. What do you think about deprecating the global > keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and > $_POST read-only as they should be used only to read-only anyway. I do not believe that making these read-only is going to yield any performance benefits and the chances of this breaking many scripts is quite large. -1 Ilia --- One other potential negative... By making them read only, are you removing the ability to scrub/delete them? Surely this is bad point? J -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
-Original Message- From: Andrey Hristov [mailto:p...@hristov.com] >James Butler wrote: >> +1 million because GLOBAL scope is horrid (generally) and is thoroughly >> abused >> -1 million because it will be the most horrific BC break since time began >> and I imagine it will break so much code that is currently in the wild... >how hard it will be to grep for "global" and $GLOBALS? Not hard for you or I but what about the beginners out there, will they know how to find them or work around the use of globals? >> In short I like it but I'm not sure how it would ever get implemented >> without breaking stuff... (this is where the clever core developers can >> propose some easy method I can't think of right now) >INI variable, like register_globals Sorry, I wasn't being very clear there, what I really meant to say was will there be the will to remove it considering the effects. I suppose INI is enough to allow it to be easily changed, but would it ever become a default setting of off, rather than something that can be optionally off? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
+1 million because GLOBAL scope is horrid (generally) and is thoroughly abused -1 million because it will be the most horrific BC break since time began and I imagine it will break so much code that is currently in the wild... In short I like it but I'm not sure how it would ever get implemented without breaking stuff... (this is where the clever core developers can propose some easy method I can't think of right now) -Original Message- From: Andrey Hristov [mailto:p...@hristov.com] Sent: 09 December 2010 10:14 To: PHP Internals List Subject: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only Hi guys, the topic says most of it. What do you think about deprecating the global keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and $_POST read-only as they should be used only to read-only anyway. The reason for global + GLOBALS is that these are abused and which leads to spaghetti programs, when used by unexperienced users. Also they have impact on side effects from functions that don't only rely their parameters. Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
On 2 Dec 2010, at 19:46, "Christopher Jones" wrote: > > > On 12/02/2010 11:23 AM, James Butler wrote: >> Following that logic, they will expect the next major version number, >> whatever it is, to have Unicode. Nothing can be done about that apart from >> telling the world it won't, including it in, or let them find out for >> themselves... >> > > If we decide the next major version doesn't have unicode then we will > have to manage/expect some community confusion. This will happen > regardless of designated version number. > > Chris Sorry, I think I misinterpreted what you were saying. You are right, the user expectation will probably need to be managed, irrespective of major version number, for quite a few features that PHP6 was expected to bring, and also any features that will now arrive that are orthogonal to what PHP6 books/media have promised. That said if the next version is 7 / 2011 / whatever, at least it won't return stacks of obsolete and outdated articles, blog posts and books when people start googling it for help and information. Just my tuppence ha'penny. . > >> -- >> James Butler >> Sent from my iPhone >> >> On 2 Dec 2010, at 19:02, "Christopher Jones" >> wrote: >> >>> >>> >>> On 11/26/2010 11:15 AM, Zeev Suraski wrote: >>>> 3. The motivation to skip 6 doesn't stem from marketing at all. The main >>>> motivation is that there's a VERY concrete perception amongst many users >>>> about what PHP 6 is. It's unlikely that PHP 6 will actually be that. >>>> Skipping this version makes perfect sense from just about any POV I can >>>> think of. That's actually one thing I do feel more strongly about - we >>>> should probably not reuse the version number 6.0 for something that's >>>> completely different than what we've been talking about for several years, >>>> whether it's now or anytime in the future. >>> >>> Users aware of PHP 6's unicode intentions will assume PHP 7 is a superset of >>> PHP 6 and therefore has unicode. So skipping the number "6" won't resolve >>> any user confusion. >>> >>> Chris >>> >>> -- >>> Email: christopher.jo...@oracle.com >>> Tel: +1 650 506 8630 >>> Blog: http://blogs.oracle.com/opal/ >>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> > > -- > Email: christopher.jo...@oracle.com > Tel: +1 650 506 8630 > Blog: http://blogs.oracle.com/opal/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Hold off 5.4
Following that logic, they will expect the next major version number, whatever it is, to have Unicode. Nothing can be done about that apart from telling the world it won't, including it in, or let them find out for themselves... -- James Butler Sent from my iPhone On 2 Dec 2010, at 19:02, "Christopher Jones" wrote: > > > On 11/26/2010 11:15 AM, Zeev Suraski wrote: >> 3. The motivation to skip 6 doesn't stem from marketing at all. The main >> motivation is that there's a VERY concrete perception amongst many users >> about what PHP 6 is. It's unlikely that PHP 6 will actually be that. >> Skipping this version makes perfect sense from just about any POV I can >> think of. That's actually one thing I do feel more strongly about - we >> should probably not reuse the version number 6.0 for something that's >> completely different than what we've been talking about for several years, >> whether it's now or anytime in the future. > > Users aware of PHP 6's unicode intentions will assume PHP 7 is a superset of > PHP 6 and therefore has unicode. So skipping the number "6" won't resolve > any user confusion. > > Chris > > -- > Email: christopher.jo...@oracle.com > Tel: +1 650 506 8630 > Blog: http://blogs.oracle.com/opal/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
Is this going to make it harder for newbies to pick up OOP from a code readability point of view when they look at other people's and framework's code? Also my IDE autocompletes it for me (maybe I'm being lazy here) so I don't see the overhead as being too onerous ( my personal view though) -- James Butler Sent from my iPhone On 28 Nov 2010, at 14:02, "Daniel Convissor" wrote: > Hi Again: > > On Sat, Nov 27, 2010 at 08:43:40PM -0500, Daniel Convissor wrote: >> >> Not that my vote really counts, but -1. Doing so would eliminate the >> helpful ability to grep source code for 'function bar'. > > It also will trip up the multitude of PHP IDE's and editors. Plus it > reduces code portability. All for saving us making a typo and having to > write "function"? > > --Dan > > -- > T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y >data intensive web and database programming >http://www.AnalysisAndSolutions.com/ > 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Hold off 5.4
Slightly brambly thoughts... I think (imho) the PHP6 hype in user land died down long ago after it became obvious it wouldn't materialise any time soon. It would be nice to see 6 to appear if only to break the (apparent) deadlock that the Unicode stuff brought on(I realise this is not enough justification by itself) What will this mean to all the Hosting providers etc who are still finishing long running 4->5 or 5.x -> 5.3 migrations? Will they resist change more because it looks like a bigger change regardless of the underlying code? As they provide installs/hosting for what I can guess to be a huge amount of the PHP's actual users is it factor that's worth considering I realise this is a Friday afternoon category comment but it can't wait.. Think of all of those PHP6 books that will be reduced to near junk status in swift branch/commit action And as a bonus -Original Message- From: Jani Taskinen [mailto:jani.taski...@iki.fi] On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote: > 2010/11/25 Jani Taskinen : >> Who says it has to be 5.4? People seem to be a bit fixated on the version >> there. > > I'd like to know too... > >> Major BC breaks just means the version released from trunk is 6.0. And it's >> just a number. Big number, but still just a number. > > Well, such a change tends to create a big buzz, without mentioning > stuff like certifications, trainings,... This is a joke, right? > We should avoid creating a virtual PHP 6.0 which will contain all the > BC stuff while all features appears in 5.x. > By doing so we will keep some shit in 5.x forever and won't have > anything appealing enough to migrate to 6.0 ..or have something really new and interesting in PHP 7.0.0. The big version number change is reserved for BC changing stuff, not just for "fancy new stuff". --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Release Process
-Original Message- From: Matthew Weier O'Phinney [mailto:weierophin...@php.net] Sent: 23 November 2010 14:18 To: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Release Process On 2010-11-23, Derick Rethans wrote: > On Tue, 23 Nov 2010, Ferenc Kovacs wrote: > > > All the rest you write in the RFC is basically already as we do it. > > > > yeah, maybe, but they aren't written down, accepted and well-known rules, so > > you can forgot/misunderstand/bend them. :/ > > And I don't think that is a bad thing. It's good to be able to be > flexible. A good artist is capable of great flexibility within the constraints of their medium. In the case of software releases, you can still have greate flexibility even with an existing release process. In many ways, having the process defined helps bring about creative solutions -- "if I want to get this in time for the release, what solution will work best?" I used to love the ad hoc nature of "we'll release when it's ready." However, having done quite a number of scheduled releases, I've found that: * Predictability motivates developers. "Release is in 3 months? Okay, let's get rolling on this!" * Knowing when the next release is coming also means that developers are more comfortable if they're unable to make the deadline. "I can't do it by this release, but I should have no trouble making the next." * Less stressful for release managers. If the code isn't ready by the deadline, it's not merged to the branch, plain and simple. The status quo works great for those whom it serves. For everyone else, it stinks. There's no transparency, which leads to disenfranchisement. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc +1 PHP is big/grown-up/widely-used enough now that "shipping is a feature" It's gone beyond just being a beginners tool for knocking out basic web pages. Enterprise (who-ever that is :-) now uses PHP and as such will want PHP to have some degree of uniformity with release cycles and feature addition/removal so that they can easily factor it in to their own deployment/upgrade plans etc. While they dislike change (tongue in cheek), they dislike the unknown more. Transparency also helps people get on board from both a developer perspective and user one too. It gives little people the warm and fuzzy feeling because they can at least understand how everything works/decisions are made even if they aren't involved in them, and if they did want to get involved, they can see what they have to do. just my 2 cents. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Release Process
Just a thought from a non-dev Rules/policies/procedures/process should always be written down or recorded somewhere, otherwise how do you know what they are? and how do you make sure changes to those rules are known about? Having a central place that every can reference (wiki) makes a ton of sense. This doesn't mean they have to be inflexible. Flexibility is down to how those rules etc are written. this is fairly basic service management sort of stuff. (No i am not proposing bringing in ITIL/CMMI would be sensible) By having this sort of stuff in the wiki, you are making it easier for new people to get up to speed and reduce the arguments over what the agreed method of doing X is. James -Original Message- From: i...@tyrael.hu [mailto:tyr...@gmail.com] On Behalf Of Ferenc Kovacs Sent: 23 November 2010 14:10 To: Derick Rethans Cc: Felipe Pena; internals Subject: Re: [PHP-DEV] [RFC] Release Process On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans wrote: > On Tue, 23 Nov 2010, Ferenc Kovacs wrote: > > > > All the rest you write in the RFC is basically already as we do it. > > > > yeah, maybe, but they aren't written down, accepted and well-known rules, > so > > you can forgot/misunderstand/bend them. :/ > > And I don't think that is a bad thing. It's good to be able to be > flexible. > > Derick > > Its good for you, but its bad for the people, who expect you to follow the rules, you know, the vendors, developers, etc. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Magic quotes in trunk
The only problem I can see with this is... do we wait for PHP6 as it seems to
be becoming a bit of a Perl 6 (sorry for bringing this up)?
I completely agree with it should only happen with major version change and
most people won't see 5.x -> 5.y being a major change and therefore the end
user expectation will be for things to generally to carry on working
I'm not sure what the best answer is apart from jumping ahead with a PHP6, but
is it really worth jumping the gun just for MQ's etc?
-Original Message-
From: patrickalla...@php.net [mailto:patrick.alla...@gmail.com] On Behalf Of
Patrick ALLAERT
Sent: 18 November 2010 10:41
To: Kalle Sommer Nielsen
Cc: Internals
Subject: Re: [PHP-DEV] Magic quotes in trunk
2010/11/17 Kalle Sommer Nielsen :
> Greetings
>
> I wanted to raise this topic before we go Alpha with trunk, regarding
> our beloved magic_quotes feature. There seems to be mixed opinions
> regarding it so I thought I would take it up for discussion.
>
> We have advised people not to use magic_quotes, register_globals and
> the like for years, and they were marked as deprecated in 5.3.0+ if
> activated through their php.ini directives. Yet magic_quotes still is
> set to "On" in 5.3.0. I think its worth we either remove the feature
> or disable it in trunk as its a security related feature. Lets have a
> look at what each of those options means:
>
> Removing magic_quotes):
> Means we will remove the feature entirely in the source, we will throw
> an E_CORE_ERROR if activated so people who have it enabled are forced
> to disable it and make their applications work without magic_quotes.
> This creates a minor issue for the hosts that simply disable it and
> have their customers applications run without them which can create a
> security risk for them, although it should be fairly limited. The
> functions to check for magic_quotes_runtime should however stay for BC
> to avoid applications that run on multiple versions of PHP from doing:
> if(function_exists('...') && ...)
>
> Disabling them):
> This will help to disable the spread of magic_quotes even more, and it
> can safely be removed in the next major version of PHP.
>
>
> My personal vote here goes towards removing them entirely.
>
>
> What are your inputs on this matter?
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
I am all for removing it but...
Disabling it by default is the first mandatory step, [done] in PHP
5.3, magic_quotes_gpc has been turned off by default at the same time
as providing a -development and -production version of the php.ini
file.
However, such a change might be risky in the PHP5 series!
Release the exact same thing as PHP 5.4 or PHP 6, there is a big
difference in the user perception.
* Is my PHP 5.x application compatible with PHP 6?
* Chance is higher that they will take more care reading a PHP 5.3 ->
PHP 6 Migration guide than a 5.3 -> 5.4.
+1 to remove it in PHP > 5
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Magic quotes in trunk
Are the £1 hosting companies going to be using 5.4+ any time soon? I'm still
coming across hosts who still transition 4.X -> 5.1/2.
I think these slow moving hosts are going to form a natural time delay between
any changes now and these changes taking affect on the parts of the user
community who this will catch out, which (hopefully) should allow ample time
for education and 'getting the word out'.
And also, how far and long do you go to protect people from what is now an
ugly/wrong/nasty feature of the language? Unless the proposal to get rid of
MQ's is dropped (shudder), Its going to have go at some point and it would seem
daft to try and wait until every app written that requires it to die out. And
the longer the feature is on/usable, the more new code written that might
really on it.
Just my 2 cents
James
-Original Message-
From: Johannes Schlüter [mailto:johan...@schlueters.de]
Sent: 18 November 2010 09:51
To: Adam Harvey
Cc: Zeev Suraski; Larry Garfield; internals@lists.php.net
Subject: Re: [PHP-DEV] Magic quotes in trunk
On Thu, 2010-11-18 at 15:40 +0800, Adam Harvey wrote:
> Yes, killing magic quotes will likely increase the support workload
> for a time,
I don't think it would increase support workload. Most people won't
notice.
What happens is that applications which are _a bit_ secure now will
continue to run as before but become _completely_ insecure as there,
unfortunately, are many users who don't know about the different issues.
Code like
mysql_query("SELECT id FROM table WHERE name = '".$_GET['name']."'");
is not too easy to exploit right now. As soon as m_q is gone it's
trivial to exploit. And people won't notice. And lots of such code
exists. Maybe not with internals subscribers, but there are enough
people who learned programming just last week using PHP and have the $1
hosting package ... and many of these things live "forever".
I think the default can only be changed in a change which breaks "a
lot".
To be clear: I am NOT saying that m_q is secure or safe. But dropping it
lowers he bar quite a lot.
johannes, who said this in multiple threads before ;-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Magic quotes in trunk
+1 for removal, magic quotes stopped being a 'good' thing to do back when I first learnt what echo did. Web hosts etc have plenty of version numbers to catch up on/upgrade too before they get to this being a problem. (well most anyway) -Original Message- From: ka...@php.net [mailto:kalle@gmail.com] On Behalf Of Kalle Sommer Nielsen Sent: 17 November 2010 16:09 To: Internals Subject: [PHP-DEV] Magic quotes in trunk My personal vote here goes towards removing them entirely. What are your inputs on this matter? -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GPU Acceleration
As a slight side note, GPUs have been (and mostly still are) used for high performance workloads where squeezing as much useful 'work' per cycle is the order of the day. CUDA et al still hasn't hit the mainstream fully and is pretty niche. Unfortunately PHP being an interpreted language isn't going to be as efficient (yet? :-) ) as C or machine code and therefore you will lose some/alot of the advantage of going GPU. However that is not a reason not to have a go (fork maybe?), something cool may come about from it. Nothing ventured, nothing gained. -- James Butler Sent from my iPhone On 13 Nov 2010, at 00:29, "Andi Gutmans" wrote: >> -Original Message- >> From: Scott MacVicar [mailto:sc...@macvicar.net] >> Sent: Friday, November 12, 2010 8:22 AM >> To: Stefan Marr >> Cc: Kenan Sulayman; PHP internals >> Subject: Re: [PHP-DEV] GPU Acceleration >> >> What's not constructive about it? Seems pretty constructive to me. The >> original >> poster has done research into the issue already. > > What research are you referring to? I must have missed that. > There's no magic with GPUs. There are good reasons why few > applications/infrastructure components use them. GPUs can be useful for very > specific workloads but not necessarily general purpose app server. > Btw there are also some workloads that could benefit from leveraging some of > the x86 extensions around encryption, vector computation, ... > So it boils down to being more specific re: where you think it could benefit > and why. > Andi > >> The reason most things don't exist is that no one has a patch for it. If it >> doesn't >> core in core then it heads into a PECL module or lives as a patch on some >> site. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] multiple sapi (multiple bug reports)
Just an uninformed thought, trunk? This isn't a problem in the runtime, just an installation annoyance for those who compile from source. Leave the patch for people who want/need it for current versions. I imagine if this has been a major problem for people (and I don't) they will have been compiling binaries separately already. -- James Butler Sent from my iPhone On 12 Nov 2010, at 22:58, "Jani Taskinen" wrote: > I updated the patch: > > http://pecl.php.net/~jani/patches/multi-sapi.patch > > Now it will fail if no sapi/binary is selected. And "make install" will > now also install them all. :) > > The question remains: into what branches can I commit it? > Some might think it's not a bug fix.. ;) > > --Jani > > > 12.11.2010 10:23, Jérôme Loyet kirjoitti: >> 2010/11/12 Jani Taskinen: >>> >>> And here's the patch: >>> >>> http://pecl.php.net/~jani/patches/multi-sapi.patch >>> >>> Note: It's not quite finished, the 'make install' might not work.. ;) >> >> After a very quick try, there is a missing case: if not SAPI and no >> binaries have been selected, we should trigger an error message. The >> configture is terminating normaly et make does nothing (normal). >> >> ++ Jerome >> >>> >>> --Jani >>> >>> >>> 12.11.2010 2:40, Jani Taskinen kirjoitti: >>>> >>>> I'm working on an improvement on how all binaries are build thus >>>> enabling building all such in one go if one wants to. I already added a >>>> check for multiple sapi _modules_ being build, it will error out. >>>> >>>> Stay tuned, I'll post the patch once I've tested it a bit. >>>> >>>> --Jani >>>> >>>> >>>> 12.11.2010 0:03, Jérôme Loyet kirjoitti: >>>>> >>>>> 2010/11/11 Jani Taskinen: >>>>>> >>>>>> 11.11.2010 18:46, Kalle Sommer Nielsen kirjoitti: >>>>>>> >>>>>>> Hi Jérôme >>>>>>> >>>>>>> 2010/11/11 Jérôme Loyet: >>>>>>>> >>>>>>>> If this is a normal behaviour, we should add an error at configure >>>>>>>> telling that only one SAPI is supported at once. >>>>>>>> It not, we should correct it. >>>>>>>> >>>>>>>> Did I miss something ? >>>>>>> >>>>>>> On Windows we have no problems in compiling multiple SAPI's using one >>>>>>> ./configure, so I believe it is indeed a bug on the Unix build system >>>>>>> causing this, so yeah I suppose it should be fixed. >>>>>>> >>>>>> >>>>>> Sascha explained this briefly here: >>>>>> >>>>>> http://www.mail-archive.com/php-...@lists.php.net/msg00413.html >>>>> >>>>> I understand it's hard to compile mutiple SAPI (dependancies, linkage, >>>>> ...). In this case, this should be clear at configure and an error >>>>> message should be shown. It's not reasonable not to be able to compile >>>>> CGI and apache2 sapi without any informations (like >>>>> http://bugs.php.net/53271). >>>>> >>>>> I've made a quick patch (http://pastebin.com/jUGMtSjv) which: >>>>> >>>>> - move the sapi/cgi/config9.m4 to config.m4. The reason cgi sapi uses >>>>> a config9.m4 file is to be called at configure as the last SAPI. >>>>> >>>>> - remove the "No SAPI selected" check in sapi/cgi/config.m4. To me >>>>> it's not its job. It has to be done by configure. To me, the cgi sapi >>>>> must be like any of the others >>>>> >>>>> - change the cgi sapi to be disable by default. cgi sapi will be like >>>>> any other sapi (except cli), disable by default. Basically, PHP is a >>>>> programming scripting language. The CLI has to be enable by default >>>>> and other sapi have to be enabled by the user. >>>>> >>>>> - add a "No SAPI selected" check in configure.in, after >>>>> "esyscmd(./build/config-stubs sapi)" (after all sapi config*.m4 files >>>>> have been executed). Use CLI as default SAPI if it's not been >>>>> disabled. If all SAPI and CLI have been disabled, issue the error >>>>> message. >>>>> >>>>> - A a check in PHP_SELECT_SAPI (in acinclude.m4) to ensure it's been >>>>> called only once (all SAPI (except CLI) calls this macro). At second >>>>> call, an error message telling that only one SAPI can be compiled is >>>>> shown. >>>>> >>>>> I don't have a huge php core background but it seems (for me at least) >>>>> the right way for users. >>>>> >>>>> hope it helps. >>>>> >>>>>> >>>>>> Something called ZTS also comes to my mind.. >>>>> >>>>> It's not the first time ZTS comes in the discution about multiple >>>>> SAPI. I've made some tests and looked into the code of the build >>>>> chain, but I can't see how it's related. Maybe someone can enlight me >>>>> ? >>>>> >>>>> thx >>>>> >>>>> ++ jerome >>>> >>>> >>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] More formal feature request cycle
Ah-ha, excellent. I'll get reading. With the the current 5.3.4 effort occupying peoples time and other constraints I'll probably leave proposing anything until the new year. If anyone has any suggestions in the meantime I'd be glad to hear them. James B On 6 Nov 2010, at 02:11, "Herman Radtke" wrote: >> Stas - quick question - what is a PEP? > > Python Enhancement Proposal > > http://www.python.org/dev/peps/ > > There is even a PEP for PEP. > > -- > Herman Radtke > hermanrad...@gmail.com | http://hermanradtke.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] lenient datetime
Like the idea, Couple of questions... What would happen if the string contained a matching pattern twice or me, which would be 'returned', also does this allow the rest of the string to be pretty much junk. (haven't had time to test patch as miles from a computer) -- James Butler Sent from my iPhone On 3 Nov 2010, at 17:16, "Stas Malyshev" wrote: > Hi! > > As I previously noted, in DateTime module there's no way to make > DateTime format parser to parse the string if the string contains more > data that the format supplies - i.e. if you need 'Y-m-d' and you have > string '2010-11-02 12:30' - you can't make DateTime accept it without > pre-parsing. The attached patch adds format character '+' that > implements that - i.e., if you use format 'Y-m-d+' then the string > '2010-11-02 12:30' will be parsed successfully, as well as '2010-11-02' > and string with anything following the date. > The character would make the format 'lenient' when used in any position > in the string, doesn't have to be at the end. > > Any objections? If not, I'll add some unit tests and commit it. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] More formal feature request cycle
Stas - quick question - what is a PEP? Is the best way forward for this. I think some discussion about what we want this to achieve and maybe a rough idea of how it could be done would be a good start. Not sure it would fit into an RFC (correct me if'm wrong). Also if this conversation needs to move somewhere else, let me know Regards, James -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: 16 September 2010 18:56 To: Christian Kaps Cc: Frederic Hardy; James Butler; internals@lists.php.net Subject: Re: [PHP-DEV] More formal feature request cycle Hi! >>> This thought is brought on mainly by watching the annotations >>> drama that is currently occupying internals, does anyone else >>> agree it might be a good idea to have a slightly more formal >>> procedure for requesting features and then recording votes pros, >>> cons, side effects, etc. against it. It might do a fair bit to >>> stop anecdotal talk of how many people actually want a feature, >>> and stop the list retreading the same arguments over and over >>> again. Have no idea just yet what this would look like, but an >>> thinking something between launchpad and the current php wiki. I agree that some rules about how we do this would be good. PHP now is big enough and complex enough and the community is diverse enough that we can engage in a discussion for months and the only result would be that everybody is so exhausted that they lose the understanding where we are, what we arrived at and nobody has any idea what's going on. And then people get frustrated and resort to cowboy comitting, etc. We do not need to have bureaucracy like Java, but some semi-formal process with results being recorded - as PEPs, for example - would do good, IMHO. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
-Original Message- From: Alexander Schrijver [mailto:alexander.schrij...@gmail.com] Sent: 01 November 2010 12:19 To: Stefan Marr Cc: Dennis Haarbrink; Stan Vass; internals@lists.php.net Subject: Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON On Mon, Nov 01, 2010 at 12:59:54PM +0100, Stefan Marr wrote: > > On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: > > Its a minor change and an annoyance to a lot of people. Yes, by not changing > > this you'r annoying thousands of people. > Instead of going for this cosmetic nonsense you should help those people on > the lemon branch. > I am insulted every time I have to read a parser token name in an error > message, instead of a sensible error message. > The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current > mumbo-jumbo is completely insignificant compared to the cost of actually > understanding the error message just indicating what the parser would have > expected. > > Changing to lemon is the only way to actually achieve something in the long > run... Right, and be forced to introduce some bullshit hebrew when its done. No, thank you. Err, the entire point is that it won't matter what the underlying token is. The error as seen can be anything you want it to be, or at least you can have a fight about what the new message looks like and i'm sure there won't really be a compelling reason for it to be in hebrew (unless localized). Please grow up... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [SPAM] Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
+1 This solves lots of other problems we have and will have in the future. -- James Butler Sent from my iPhone On 1 Nov 2010, at 12:00, "Stefan Marr" wrote: > > On 01 Nov 2010, at 12:06, Alexander Schrijver wrote: >> Its a minor change and an annoyance to a lot of people. Yes, by not changing >> this you'r annoying thousands of people. > Instead of going for this cosmetic nonsense you should help those people on > the lemon branch. > I am insulted every time I have to read a parser token name in an error > message, instead of a sensible error message. > The cost of understanding T_PAAMAYIM_NEKUDOTAYIM as part of the current > mumbo-jumbo is completely insignificant compared to the cost of actually > understanding the error message just indicating what the parser would have > expected. > > Changing to lemon is the only way to actually achieve something in the long > run... > > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
>From a completely separate stand point. The ability to customise what token >names show up as in an error seems like a much better solution -- James Butler Sent from my iPhone On 30 Oct 2010, at 21:41, "Chad Emrys" wrote: > On 10/30/2010 03:32 PM, Etienne Kneuss wrote: >> lemon would indeed get rid of actual "names" for such tokens, and would >> rather display "unnexpected ::". >> >> The problem with lemon is that it turns out to still be a tad bit slower >> than yacc, with some complications on the grammar side (the compiler >> helper functions were made for yacc). So unless there is a major speedup >> breakthrough, it won't happen in a near future, sadly. >> >> > > So does that leave us back to square 1 with replacing the token name? Or > is there another way that error messages can be tweaked to not show > actual token names? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Are you supporting users who you provide a shared hosting embodiment too, and do you control binary installations on the enviroments? If so then possibly patching source for you installs maybe the easiest and quickest solution. If we knew the nature of your support requirements, then we could possibly suggest a better solution or be won round. (although internals isn't the place for that really) This is not meant to bait but possibly an improvement in your support process or docs might yield a solution? -- James Butler Sent from my iPhone On 30 Oct 2010, at 17:51, "Chad Emrys" wrote: > On 10/30/2010 11:43 AM, James Butler wrote: >> If it ain't broken don't fix it. >> >> Change for the sake of it is a bad thing. It does things like introduce bugs >> etc. >> >> Q1) is it broken? >> Q2) if yes exactly what is broken >> Q3) does the proposes fix solve the root cause? >> >> I'm not sure changing the token name is the correct fix to people not >> knowing what the error means. >> >> -- >> James Butler >> Sent from my iPhone >> > Q1) yes, it is broken, people have to Google or ask around for a very > unclear error message when for the most parts errors are (and should be) > self explanatory. > > Q2) Two things are broken: Either the token is named badly, or the > token names shouldn't show up in error messages at all and be replaced > with something a bit more friendly. > > Q3) those two fixes above would probably fix that, yes. > > What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on > LINE 23 they are gonna look for a double colon on line 23? because they DO. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
If it ain't broken don't fix it. Change for the sake of it is a bad thing. It does things like introduce bugs etc. Q1) is it broken? Q2) if yes exactly what is broken Q3) does the proposes fix solve the root cause? I'm not sure changing the token name is the correct fix to people not knowing what the error means. -- James Butler Sent from my iPhone -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
As a further reason, (not that I think that's it needed) When doing anything vaguely specialist, e.g engineering, medicine, sport, you require a precise set of terminology so two or more people can communicate clearly. The result of this is that if you want to play in a domain, you must be prepared to learn and use domain specific language/terms/acronyms. The double colon is example of this. We can lead the horse to water, but we can't make him drink. -- James Butler Sent from my iPhone > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
I'll bite. Why should this be changed? Is it broken? Is it something that 1 second on google can't answer? If somebody is advanced enough to be using classes (I think about the only time you would use a double colon) then they should know what it means. -- James Butler Sent from my iPhone On 30 Oct 2010, at 02:51, "Chad Emrys" wrote: > On 10/29/2010 08:24 PM, Scott MacVicar wrote: >> On Oct 29, 2010, at 6:17 PM, admin wrote: >> >> >>> On 10/29/2010 08:11 PM, William A. Rowe Jr. wrote: >>> >>>> On 10/29/2010 7:47 PM, admin wrote: >>>> >>>> >>>>> WTF is T_PAAMAYIM_NEKUDOTAYIM? >>>>> >>>>> This has to be THE most asked question by new php developers when they >>>>> come across it. >>>>> Can we please change the token name to T_DOUBLE_COLON so I don't have to >>>>> hear about it >>>>> constantly? >>>>> >>>>> Those that disagree don't do enough PHP support to know how often it is >>>>> asked. it's worth it. >>>>> >>>>> >>>> Is it that hard to at least review the mailing list archives before >>>> ranting? >>>> >>>> At least posters would sound like they have educated themselves on why what >>>> came to be, and argue sensibly for changes. >>>> >>>> >>>> >>> obviously the old arguments didn't work, time to start anew. >>> >>> >> using a name like "admin" in your email headers isn't going to be very >> receptive. >> >> For what its worth its Hebrew for double colon. I'm all for the change, will >> see what I can do next week. >> >> - S >> >> > Oops, sorry didn't even notice it was there, I don't send mail from this > account much. > > Should be fixed. Though I don't care what my name has to do with reception. > > What is in a name anyway? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] docBlock Parser RFC
FWIW, I am in favour of something that allows the parsing of DocBlock comments (should it just be DocBlock comments though?) and am implementation agnostic so far (i have too little understanding of where in the core/extensions this would need to sit). This would then allow developers to hack on top annotations (or another RFC and do it properly) and anything else they wanted without having DocBlock parsing explicitly tied to annotations (which the internals thread seems have cemented in everyone's mind). James -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PHP Annotations RFC + Patch
+1 for annotations -1/2 for parsing comments - it just doesn't seem right -Original Message- From: Zeev Suraski [mailto:z...@zend.com] Sent: 16 September 2010 17:01 To: Guilherme Blanco Cc: Gustavo Lopes; Derick Rethans; internals@lists.php.net Subject: Re: [PHP-DEV] Re: PHP Annotations RFC + Patch At 16:34 16/09/2010, Guilherme Blanco wrote: >So the question to be answered is: Should PHP support Annotations? -1 for introducing a new Annotations concept and associated syntax +1 for adding APIs to parse doc blocks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] More formal feature request cycle
This thought is brought on mainly by watching the annotations drama that is currently occupying internals, does anyone else agree it might be a good idea to have a slightly more formal procedure for requesting features and then recording votes pros, cons, side effects, etc. against it. It might do a fair bit to stop anecdotal talk of how many people actually want a feature, and stop the list retreading the same arguments over and over again. Have no idea just yet what this would look like, but an thinking something between launchpad and the current php wiki. -- James Butler Sent from my iPhone -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch
I might be wading into this a bit fast but At a very simple level, comments are not meant to be parsed by design. Hence commenting out code so it is not parsed! How would one tell the parser not to read docblock annotations as there wouldn't be a mechanism to comment them out? Lots of people use comments to stop some of their code being executed for testing etc. I'm indifferent currently towards annotations and their usefulness but I really don't think they should sit in comments -Original Message- From: Guilherme Blanco [mailto:guilhermebla...@gmail.com] Sent: 15 September 2010 17:18 To: Lars Schultz Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Re: Re: PHP Annotations RFC + Patch It's curious that you keep complaining about new syntax and propose a new one at the same time. [Foo] introduces new concept, use /** @Foo */ or /** [Foo] */ instead. What's the point then? I think meta programming is not and would never be part of comment. As previously said, docblock means documentation, without any meaning to parser, entirely human readable and totally removable without affecting overall execution. Something that HAS a meaning to execution means something out of the userland comments. Point made. Cheers, On Wed, Sep 15, 2010 at 6:45 AM, Lars Schultz wrote: > listen to this man;) I think he's on to something. I don't see any problem > with that aproach and both parties would be satisfied, no? > > Am 15.09.2010 10:45, schrieb Benjamin Eberlei: >> >> Hi Zeev and Stas, >> >> >> >> I wouldnt mind extending doc block metadata support instead of adding a >> >> new syntax. >> >> >> >> I agree with you that PHP Docs allow metadata and they can be used for >> >> that (and some people do, including me), however what the annotation patch >> >> + rfc tries to achieve is something going beyong $refl->getDocComment() >> >> returning a string only. The string only return leads to hunderets of >> >> different approaches for annotating metadata in all the different >> >> frameworks and libraries. A single unified syntax would be benefitial. >> >> >> >> That is why I don't know if it will even be possible to extend the doc >> >> blocks in a generic way that does not break half the applications out >> >> there. >> >> >> >> When extending doc-blocks there is probably new method required >> >> $refl->getParsedDocComment() which then returns an array of metadata for >> >> that particular refl instance. Now here the syntax would be a problem, can >> >> we find something that does not break for all the different usages of >> >> docblocks out there? Since the method/parsing would be nested, on request >> >> only it wouldnt break any application that does not use parsed doc >> >> comments. However for applications that do, a syntax needs to be found >> >> that: >> >> >> >> 1. does not break for various type hinting doc syntaxes >> >> 2. does not break for various commenting styles >> >> >> >> Can someone come up with additional pitfalls? >> >> >> >> greetings, >> >> Benjamin >> >> >> >> On Wed, 15 Sep 2010 08:55:55 +0200, Zeev Suraski wrote: >> >> >> >> At 08:09 15/09/2010, Stas Malyshev wrote: >> >> >> >> Phpdocs aren't "user documentation" only, not for a long time (I >> >> mean the concept, not the particular application called phpDocumentor, of >> >> course). They are being used as metadata in many places. You could argue >> >> that's misguided but you can't ignore the fact that's what people do. The >> >> "goals and usages" of those tags are exactly metadata - and regardless of >> >> the annotations, I'd be happy if Reflection recognized it finally (by >> >> integrating some kind of phpdoc tag parser). >> >> >> >> I second that word for word. FWIW, I don't see it as misguided at all. >> >> Zeev >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
