Re: [PHP-DEV] Re: Hold off 5.4

On Thu, Dec 2, 2010 at 11:01 AM, 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 unli

[PHP-DEV] PHP 5.2.15RC2 & 5.3.4RC2 Released for Testing

The second release candidates of 5.2.15 and 5.3.4 were just released for testing and can be downloaded here: http://downloads.php.net/ilia/php-5.2.15RC2.tar.bz2 (md5sum: 423e70e49f8defd63c6a08d824357f36) http://downloads.php.net/johannes/php-5.3.4RC2.tar.bz2 (md5sum: 36f7854304f9ecaa28d56f0eb

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, includ

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

Having thought a bit about this, there are a couple of initial problems I see, and, more importantly, I'm not convinced that the stated problem (encapsulation) requires the addition of a new language construct (i.e. a "property" as distinct from a "class member"). In fact, I think it is better impl

Re: [PHP-DEV] Re: Hold off 5.4

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

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, "Chri

Re: [PHP-DEV] Re: Hold off 5.4

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 pe

RE: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())

On Tue Nov 30 03:26 AM, Julien Pauli wrote: > I guess serialize mechanism cant use any char that can be part of a > PHP variable. And "_" can. As property names respect binary > compatibility, the only char that can be used to mark private > properties is actually the NULL byte. Ping me if I'm w

Re: [PHP-DEV] git anyone?

On 12/2/10 5:33 AM, Lester Caine wrote: Again you are missing the point here. CVS/SVN works nicely for managing a master code base. DVCS does not naturally support that, and this is a major area that needs to be managed by any project switching so that you CAN manage a master codebase. I used

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

-1 On 11/27/2010 08:40 PM, Johannes Schlüter wrote: > Hi, > > every now and then while writing classes I forget to add the "function" > keyword between my visibility modifier and the method name in a class > declaration. I don't think it is required for readability and it is not > needed by the p

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

On 12/2/10 8:42 AM, presid...@basnetworks.net wrote: How does one get a reference to a property, if a property is just a collection of methods with fancy behavior? That makes properties a first class entity, which is an entirely different bit of brain bending. Its the same concept as havi

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

On Thu, Dec 2, 2010 at 17:07, la...@garfieldtech.com wrote: > On 12/2/10 7:51 AM, Patrick ALLAERT wrote: > +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. > > I am still firmly -1 on removing T_FUNCTION for methods. > -- Patrick Allaert >>

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

On 12/2/10 7:51 AM, Patrick ALLAERT wrote: +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. I am still firmly -1 on removing T_FUNCTION for methods. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PH

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

On 2 December 2010 13:51, wrote: >> 2010/12/1 Richard Quadling >> >>> On 1 December 2010 09:22, Stas Malyshev wrote: > ... > >> Why change the expected behavior of isset? If a property has not been set >> then isset must return false, and that includes $foo->name = NULL. > > > Thats simple then

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

presid...@basnetworks.net wrote: >> Its a defacto standard. Of course there is nothing stopping PHP from >> implementing properties that way, but by going against the standard set >> by >> the rest of the industry, it is very confusing for programmers coming >> from >> other languages to l

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

Hi Larry, >> Hmm, I would have programmed it liked this: >> >> if ($account->beneficiary != null) { >> print $account->beneficiary->name; >> } >> >> To me, if a property is "not set", it means it does not exist and will >> not >> be a valid property at any point in the object's lifetime. Null

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

> See, here's the fundamental problem we're running into. There's three > different definitions of what a property is that we keep bouncing between, > each of which will dictate both syntax and semantics: > > 1) Properties are a smart masking layer over class members, like a smarter > __get/__set,

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

> presid...@basnetworks.net wrote: >> I feel that the downfall of this syntax, is that the get and set methods >> can easily be scattered at either end of a class definition. With the >> syntaxes I provided, it is easy to tell which of the methods a property >> has defined at a quick glance, becau

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

> 2010/12/1 Richard Quadling > >> On 1 December 2010 09:22, Stas Malyshev wrote: >> > Hi! >> > >> >> Its not a matter of consistency - Properties, as a cross-language >> concept >> >> are not meant to work that way. You need to think of a property as a >> set >> > >> > Meant by whom? Is there so

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

Hi Derick, >> Link to the RFC: >> http://wiki.php.net/rfc/propertygetsetsyntax > > -1 > > Derick Care to elaborate? I'm not sure much consideration will be taken of your opinion unless you put some words behind it. I am curious to know why you did not like the RFC? Regards, - Dennis -- PHP I

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

Hi Lester, >> Its a defacto standard. Of course there is nothing stopping PHP from >> implementing properties that way, but by going against the standard set >> by >> the rest of the industry, it is very confusing for programmers coming >> from >> other languages to learn PHP. A good example is

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

Hi Stefan, >> Unfortunately I find that to be one of the major downfalls of PHP. It >> sometimes disregards defacto standards that are set across the entire >> industry, which causes a lot of frustration for new programmers. >> Sometimes the functionality PHP adds by going its own way is worth it

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

Hello Stas, > In PHP, of course, class properties are dynamic, so you can add and > delete them at will. It is a standard feature of dynamic languages. For > a person coming from strict compiled language like C# it might be > unusual, but that's how dynamic languages work. No not unusual at all.

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

>> So we have one set of properties where get and isset use different >> methods >> and another set of properties where get and isset use same method but >> with >> parameter. I think it's not the best way to go. It's better to ignore >> isset >> altogether than this. > > No. The prototype of all s

Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

>> Why change the expected behavior of isset? If a property has not been >> set >> then isset must return false, and that includes $foo->name = NULL. >> >> >> Regards. >> > > Say the property is write-only. How can isset() operate on that? If > the property is read-only, how can you unset() it? I

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

2010/12/2 Peter Beverloo : > On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT wrote: >> 2010/12/2 André Rømcke : >>> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >>> wrote: Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ introducing the possible omission of T_FUNCTION? >>>

RE: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP

On Thu Dec 2 02:11 AM, Larry Garfield wrote: > > See, here's the fundamental problem we're running into. There's three > different definitions of what a property is that we keep bouncing > between, each of which will dictate both syntax and semantics: > > 1) Properties are a smart masking laye

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT wrote: > 2010/12/2 André Rømcke : >> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >> wrote: >>> Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ >>> introducing the possible omission of T_FUNCTION? >> >> Why? >> This will break lots of

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

2010/12/2 André Rømcke : > On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT > wrote: >> Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ >> introducing the possible omission of T_FUNCTION? > > Why? > This will break lots of code, does it improve anything while at it? Is 'var' > hinderi

Re: [PHP-DEV] git anyone?

dukeofgaming wrote: Such IDE integration exists for mercurial, both for Eclipse and Netbeans, also at shell level. This has already been covered ... git and hg integration is only partially functional. Git is a right pain in windows, while hg is at least functional identically in both linux a

Re: [PHP-DEV] git anyone?

Such IDE integration exists for mercurial, both for Eclipse and Netbeans, also at shell level. I really don't get why you say there is no easy way to rollback changes, because there is. I do manage package updates and installations through SVN (e.g. updating symfony, doctrine), I just don't use SV

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

How about deprecation then? On Thu, Dec 2, 2010 at 3:58 AM, André Rømcke wrote: > On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >wrote: > > > 2010/11/30 Kalle Sommer Nielsen : > > > Hi > > > > > > 2010/11/30 Patrick ALLAERT : > > >> With this patch, something looks inconsistent to me: > > >>

Re: [PHP-DEV] git anyone?

dukeofgaming wrote: Its actually faster to use the command line when u have enough practice; picture yourself merging branches or something more complicated, I think its easier typing stuff as you think it than finding your way around a GUI, command line reacts faster than a GUI too. I use the ID

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT wrote: > 2010/11/30 Kalle Sommer Nielsen : > > Hi > > > > 2010/11/30 Patrick ALLAERT : > >> With this patch, something looks inconsistent to me: > >> Both properties and methods have a visibility > >> (public|protected|private) and a keyword: "var"

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

I toast to that. Get rid of T_VAR already. Regards, David On Thu, Dec 2, 2010 at 3:34 AM, Patrick ALLAERT wrote: > 2010/11/30 Kalle Sommer Nielsen : > > Hi > > > > 2010/11/30 Patrick ALLAERT : > >> With this patch, something looks inconsistent to me: > >> Both properties and methods have a visi

Re: [PHP-DEV] git anyone?

Its actually faster to use the command line when u have enough practice; picture yourself merging branches or something more complicated, I think its easier typing stuff as you think it than finding your way around a GUI, command line reacts faster than a GUI too. I use the IDE integration though,

Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations

2010/11/30 Kalle Sommer Nielsen : > Hi > > 2010/11/30 Patrick ALLAERT : >> With this patch, something looks inconsistent to me: >> Both properties and methods have a visibility >> (public|protected|private) and a keyword: "var" (T_VAR) and "function" >> (T_FUNCTION) respectively. >> However "privat

Re: [PHP-DEV] git anyone?

dukeofgaming wrote: Yet another one here:http://hginit.com/00.html The title says it all: "Subversion re-education". It is actualyy a somewhat neutral article even though the page is a mercurial tutorial. Actually this probably point up one of the fundamental differe

Re: [PHP-DEV] git anyone?

Yet another one here: http://hginit.com/00.html The title says it all: "Subversion re-education". It is actualyy a somewhat neutral article even though the page is a mercurial tutorial. Regards, David On Thu, Dec 2, 2010 at 12:44 AM, Larry