Re: [PHP-DEV] git anyone?
Yet another one here: http://hginit.com/00.html http://hginit.com/00.htmlThe title says it all: Subversion re-education. It is actualyy a somewhat neutral article even though the page is a mercurial tutorial. Regards, David http://hginit.com/00.html On Thu, Dec 2, 2010 at 12:44 AM, Larry Garfield la...@garfieldtech.comwrote: The Drupal project's decision making process for moving to Git is documented extensively here: http://groups.drupal.org/node/48818 Just another data point. --Larry Garfield On Wednesday, December 01, 2010 2:52:53 pm dukeofgaming wrote: Hi, I was following this path to push the adoption of a DVCS for the Joomla project and I started to create the required documentation to make an informed argument and evaluation, I made some diagrams to make the case for their need for good team development and workflows, feel free to borrow any content/diagrams from here http://docs.joomla.org/Dvcs If an RFC is started I'd love to help. I have experience with git and mercurial. http://docs.joomla.org/DvcsRegards, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
dukeofgaming wrote: Yet another one here:http://hginit.com/00.html http://hginit.com/00.htmlThe 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 differences between the different ways of working. 'Most people work with Mercurial through the command line' ... fill in your own package ... Personally I very rairly use any of these from the command line, since Eclipse has fully integrated facilities. The statement 'it just works from the cammand line' only applies if that is what you are still using, but even CVS I would have to dig out the manual to use the command line. Productivity wise, having to pull out of the IDE to do code management is the main problem with switching from CVS/SVN to any of the alternatives, but the main thing I can't understand is how people actually MANAGE with command line when dealing with a large number of changes? A graphical facility is almost essential when navigating around complex code trees and viewing diffs which are more than a few dozen lines? ( Pierre this is probably one of the reasons I had so much trouble building PHP on windows ... simply because I have used graphic IDE's since C++ Builder 1 days and before :( Command line working is a somewhat different mind set ... and prior to C++ I was working on hand coded machine code ... ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.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
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
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 private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of T_FUNCTION?
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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, but not the shell integration, at all. I agree on visualizing repository tree on the GUI though. In the end its up to each individual. Regards, David On Thu, Dec 2, 2010 at 3:12 AM, Lester Caine les...@lsces.co.uk wrote: dukeofgaming wrote: Yet another one here:http://hginit.com/00.html http://hginit.com/00.htmlThe 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 differences between the different ways of working. 'Most people work with Mercurial through the command line' ... fill in your own package ... Personally I very rairly use any of these from the command line, since Eclipse has fully integrated facilities. The statement 'it just works from the cammand line' only applies if that is what you are still using, but even CVS I would have to dig out the manual to use the command line. Productivity wise, having to pull out of the IDE to do code management is the main problem with switching from CVS/SVN to any of the alternatives, but the main thing I can't understand is how people actually MANAGE with command line when dealing with a large number of changes? A graphical facility is almost essential when navigating around complex code trees and viewing diffs which are more than a few dozen lines? ( Pierre this is probably one of the reasons I had so much trouble building PHP on windows ... simply because I have used graphic IDE's since C++ Builder 1 days and before :( Command line working is a somewhat different mind set ... and prior to C++ I was working on hand coded machine code ... ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.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
I toast to that. Get rid of T_VAR already.
Regards,
David
On Thu, Dec 2, 2010 at 3:34 AM, Patrick ALLAERT patrickalla...@php.netwrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
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 private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
Shouldn't we get rid of that kind of pre-PHP5 stuff _before_
introducing the possible omission of T_FUNCTION?
Patrick
--
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
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.netwrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
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 private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
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'
hindering anything? Is it taking up a lot of code?
If it is removed then that should be in trunk aka 6.0 the 2nd , and not in
5.x.
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 IDE integration though, but not the shell integration, at all. I agree on visualizing repository tree on the GUI though. In the end its up to each individual. This is the key here. When working on PHP projects via CVS and SVN I get a view of all the files which have changed in the IDE. I can then review those changes and only need to select those which do not clash with my own local changes. I can also immediately see committed changes that NEED to be rolled back because they DO clash with the areas that I am maintaining! Simply automatically merging from the command line does not work FOR ME. DVCS in theory provides a nice way for me to manage my own builds of these projects, but the black hole is now how the clash problems are handled as there is no easy way to roll back a change that has broken something else. Adding the complexity of multiple packages across several projects ... smarty, adodb and the like, or building the internal extensions which use libraries from the likes of apache, firebird ... in theory should be simplified by the use of a DVCS approach, but the reality is that it is still very early days and while people are running to a number of camps there needs to be a more tidy integration path rather than the current diversity that has been created. I think that what we actually need is a complete rethink of what the problems are ... including managing the user projects rather than JUST raw source code ... and agree a level of operation rather than the current approach of slagging off the paths that you do not agree with. Every package has problems and none of them offer a single solution? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.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
How about deprecation then?
On Thu, Dec 2, 2010 at 3:58 AM, André Rømcke a...@ez.no wrote:
On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net
wrote:
2010/11/30 Kalle Sommer Nielsen ka...@php.net:
Hi
2010/11/30 Patrick ALLAERT patrickalla...@php.net:
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 private var $foo; generates a fatal error but private
function foo(){} not?
The var keyword is an alias of the public keyword for BC with
PHP4. So it would be illogically to declare a property both private
and public at the same time ;-)
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'
hindering anything? Is it taking up a lot of code?
If it is removed then that should be in trunk aka 6.0 the 2nd , and not
in
5.x.
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 SVN to work with other people. I believe that managing packages and working with people should not be regarded as the same thing when talking about versioning systems. I think the main and general drive of people for adopting a DVCS is just that, better workflows, and fortunately, some of them have actually worried about interoperability, meaning its possible to import files from other (D)VCSs. Regards, David On Thu, Dec 2, 2010 at 4:02 AM, Lester Caine les...@lsces.co.uk wrote: 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 IDE integration though, but not the shell integration, at all. I agree on visualizing repository tree on the GUI though. In the end its up to each individual. This is the key here. When working on PHP projects via CVS and SVN I get a view of all the files which have changed in the IDE. I can then review those changes and only need to select those which do not clash with my own local changes. I can also immediately see committed changes that NEED to be rolled back because they DO clash with the areas that I am maintaining! Simply automatically merging from the command line does not work FOR ME. DVCS in theory provides a nice way for me to manage my own builds of these projects, but the black hole is now how the clash problems are handled as there is no easy way to roll back a change that has broken something else. Adding the complexity of multiple packages across several projects ... smarty, adodb and the like, or building the internal extensions which use libraries from the likes of apache, firebird ... in theory should be simplified by the use of a DVCS approach, but the reality is that it is still very early days and while people are running to a number of camps there needs to be a more tidy integration path rather than the current diversity that has been created. I think that what we actually need is a complete rethink of what the problems are ... including managing the user projects rather than JUST raw source code ... and agree a level of operation rather than the current approach of slagging off the paths that you do not agree with. Every package has problems and none of them offer a single solution? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 and windows. BUT sub-repo is an area that is not currently supported in any of the integration tools and hg-git actually fails if there is a git sub-repo. Keeping each extension of php in it's own sub-repo is the obvious way of managing things, but is the very area that is not fully functional. Building a single 'download' of a group of packages is not something that can currently be handled, as the 'module' structure of CVS simply can't be mapped. A single CVS repo becomes 200+ separate repo's in hg or git, and you then need script files to manage things, which is fine for command line users, but a problem for the IDE approach. 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 SVN to work with other people. I believe that managing packages and working with people should not be regarded as the same thing when talking about versioning systems. 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. The problem I was trying to highlight was that with patches around a number of distributed copies, managing a 'rollback' can be difficult if several people have pushed around different paths, and currently the available tools do not allow the same flexibility that has been provided for CVS/SVN for several years. I think the main and general drive of people for adopting a DVCS is just that, better workflows, and fortunately, some of them have actually worried about interoperability, meaning its possible to import files from other (D)VCSs. Again ... there is no 'natural' workflow so it becomes a lot more difficult to cooperate. I still think that a 'master' of the CVS/SVN type may be preferable rather than trying to manage that via a DVCS maze? All of the projects that have published their research have indicated that there is not a simple answer and that the goal posts are still moving on a weekly basis? hg has published improvements to the sub-repo problem only this week, but the integration packages still have to catch up. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.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
2010/12/2 André Rømcke a...@ez.no: On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net 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' hindering anything? Is it taking up a lot of code? If it is removed then that should be in trunk aka 6.0 the 2nd , and not in 5.x. It should of course not appear in a 5.x release! But sounds like current trunk can't be anyway. +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- 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
On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT patrickalla...@php.net wrote: 2010/12/2 André Rømcke a...@ez.no: On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net 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' hindering anything? Is it taking up a lot of code? If it is removed then that should be in trunk aka 6.0 the 2nd , and not in 5.x. It should of course not appear in a 5.x release! But sounds like current trunk can't be anyway. +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. Regards, Peter Beverloo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 layer over class members, like a
smarter __get/__set, designed to make it possible to swap out in place
of class members at will. In this case, both the syntax and semantics
of properties should mirror class members as close as possible.
2) Properties are a short-hand for getFoo()/setFoo() methods (which in
the general sense should *not* be understood to always map to class
members, as discussed), designed to make typing $o-getFoo() and $o-
setFoo() shorter/easier. In this case the syntax and semantics
should
make that clear and not confuse the user with class-member-like syntax.
Right, for example:
$tp = new TimePeriod;
$tp-hours = 2;
foreach($tp as $prop = $val)
Would this be an empty loop? That seems to be what the RFC proposes (2)
layer of syntactic sugar over a pair of methods.
If a property is to provide the (1) illusion of a variable (~class
member), IMHO it provides a clear benefit over the __get(), __set() methods.
In the spirit of (1):
class Audit_Entry {
public $info;
public $timeAdded { // illusion of a variable, removed 'public property'
to avoid confusion
get {
return $this-_timeAdded;
}
isset {
return isset($this-_timeAdded);
}
};
protected $_timeAdded; // Datetime
function __get($prop)
{
// virtual properties, these are not class members
}
}
In the spirit of (2), it seems like we would have two ways of doing the same
thing.
It would probably be a good idea to deprecate __get(), __set()... in favor
of the C# style
--
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
2010/12/2 Peter Beverloo pe...@lvp-media.com: On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT patrickalla...@php.net wrote: 2010/12/2 André Rømcke a...@ez.no: On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT patrickalla...@php.net 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' hindering anything? Is it taking up a lot of code? If it is removed then that should be in trunk aka 6.0 the 2nd , and not in 5.x. It should of course not appear in a 5.x release! But sounds like current trunk can't be anyway. +1 for removing T_VAR and making T_FUNCTION optional in a major release. -1 otherwise. -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. If people migrate to a major version of PHP 5 they should at least stop relying on PHP 4 features still valid thanks to BC consideration. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. This makes much sense! -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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? If the property is write-only, I would imagine isset would return false, because there is no value to read. I think when you call isset(), you are asking, is there something for me to read?, so this would make sense. If the property is read-only, then unset would have no effect. Unsetting is a write action (like deleting a file), so if its read-only, it cannot be unset. It could possibly throw a non-fatal error too I suppose. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 setters would be the same. As would the
prototype of all getters.
The prototype would be ...
[public|protected|private] property $property {
[public|protected|private] mixed|bool get([bool $isset = false]) {
// mixed result for get, bool result for isset
},
[public|protected|private] mixed|void set(mixed $value [, bool
$unset = false]) { // mixed result for set, void result for unset
},
};
From a user's perspective ...
echo isset($instance-property) ? 'isset to ' . $instance-property :
'not isset';
This would result in 2 calls ...
property-get(true) // Let the getter that an attempt is being made to
see if the property has been set.
and
property-get(false) // Let the getter know that the getter is
expected to return the properties value.
Similarly for the setter.
$instance-property = 'foo';
unset($instance-property);
would result in 2 calls ...
property-set('foo', false) // Let the setter know that it should be
setting the value of the property to 'foo'.
and
property-set(null, true) // Let the setter know that an attempt to
unset the property has taken place.
Maybe the proposal should be changed to ...
[public|protected|private] property $property {
[public|protected|private] mixed get() {
},
[public|protected|private] mixed set(mixed $value) {
},
[public|protected|private] bool isset() {
},
[public|protected|private] void unset() {
},
};
(NOTE: Add in abstract and final as appropriate).
This last syntax makes far more sense than adding parameters to the
get/set methods. The problem however, is what does isset and unset
do/return if they are not defined? What if I only want to define the
get/set and I do not define the isset/unset? If they are required,
properties are far too complex to be useful. But if they are optional, we
are back to the same problem of what isset() and unset() are supposed to
do...
- Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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. You can dynamically add properties to class instances in C# as well. My point was that methods cannot dynamically be added or removed from class instances, even though variables can. I think what it comes down to, is it wont be possible to remove the actual property definition from the instance, but just be able to hide it, or make it appear like it is missing, to be consistent with the behaviour of standard variables. This makes for another issue though. If I unset() the property $foo, and then (because its gone), attempt to set $foo to something else, this is going to activate the property definitions set method, when I only expected a variable to be created. This is because the property definition still exists, but is just hiding (returning false from its isset handler). How should this situation be handled? - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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, but often it is just a confusing mess. Thats just my opinion though, YMMV. Still, if it is not consistent in itself it is worse than not following certain designs which make sense for other languages only. Yes, I would agree with that. isset() in the way you suggest would just be confusing. It would allow is to say that a property does not exist, when in fact it does exist. This is not logical. From the docu: isset Determine if a variable is set and is not NULL There is nothing confusing about isset($this-Hours) == FALSE in your example if isset($this-seconds) == FALSE. Right, I understand how it would work, and the reasons why it would make sense, but it just feels wrong to me. When you unset() a variable in a class, that whole variable is gone. Its not just hiding somewhere, its completely gone. If a property were to pretend it is not set, with an isset method, it would still be there - just hiding. That is why it does not make sense to me. The main problem here is that unset and isset are not symmetric. isset() basically means there is a value. Where unset() destroys the _holder_ of the value. In that sense, unset is special since it works on another level, on the same level as property_exists(). There are several possible approaches, but the main point here is that at least isset() still makes sense. property_exists() and unset() should be dealt with carefully in another way. Ok. Well isset() could just run the get handler for the property, and if it is null, return false, and otherwise return true. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 how == works differently in PHP than in other languages. In PHP, === works like == does everywhere else. (string)'0' == (int)0, for example is true in PHP, but false in most other languages. I have had countless conversations with PHP developers who claim the language is broken, because == does not work like they expect it to, after which I have to explain === to them. This is because PHP goes against the defacto standard. Maybe it would have been better if == and === had the opposite meaning, as to not squash the standard? You have got me there. = is assign == is equal value === is equal type and value At least on all the languages I've been using recently ... where is this a problem? In any language that does not have === it is like this: = is assign == is equal type and value That is where the confusion comes from. People do not expect 0 and 0 to be equal, because they are different types. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
2010/12/1 Richard Quadling rquadl...@gmail.com On 1 December 2010 09:22, Stas Malyshev smalys...@sugarcrm.com 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 some law of universe that prevents us from implementing the feature? of two methods that just have a pretty syntax. Methods cannot be unset, and nor should properties be allowed to. isset() should simply tell us whether a property with the specified name is part of the class or not. If you need methods, why not use methods? If you mimick object properties, however, it makes sense to make them work exactly like property, otherwise you have to explain why they don't work this way. isset() in the way you suggest would just be confusing. It would allow is to say that a property does not exist, when in fact it does exist. This is not logical. Sorry, from your answer I don't understand - what happens when you call isset($foo-property) and unset($foo-property)? If we think of properties as this new entity for the language (rather than somehow massaging existing entities to fit a new usage scenario), then isset($instance-property) will always return true for any defined property. Even if the getter would return null. This is new behaviour and can be easily documented. isset() for a property is more like method_exists() than isset() on a variable. With regard to unset($instance-property), from the manual ... ... 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, when isset is invoked, call the get method, and if it returns null then isset() returns false, but otherwise returns true. That was likely just a small oversight on Richard's part. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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, because everything is in on spot. Additionally, public/private/protected/final/abstract/etc only has to be specified once on the property (but can be specified separately! - see the RFC). This means less to read, and clearer, cleaner syntax. Lastly, I think that grouping the two methods just makes sense, because a property is one conceptual object, not two. Separating the two methods makes as much sense logically as does separating a class definition into two parts. - Dennis Grouping the get and set is a good convention. But grouping all the gets (doing pretty similar things) and all the sets can be as good as it. You would need to enter into each class/project to see which convention fits better. Grouping all the gets and all the sets can already be done using __get and __set. That is great when dealing with collections of data, but not good at all for dealing with individual properties. They are both meant for different situations, and I think would live quite happily along side each other. Because of that, I think grouping the get/set of an individual property is the best approach possible. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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, designed to make it possible to swap out in place of class members at will. In this case, both the syntax and semantics of properties should mirror class members as close as possible. 2) Properties are a short-hand for getFoo()/setFoo() methods (which in the general sense should *not* be understood to always map to class members, as discussed), designed to make typing $o-getFoo() and $o-setFoo() shorter/easier. In this case the syntax and semantics should make that clear and not confuse the user with class-member-like syntax. 3) Properties are a completely different animal, neither methods nor class members but a totally different concept. In this case the syntax should not be confusing with either methods or class members, and the semantics should probably then be taken from the most common/popular existing implementation feasible. We cannot mix #1 and #2 and expect to get something usable out the other end, nor can we defend doing so on the grounds of #3. The discussion of the proposal is doing exactly that, however, which I think is a fatal flaw. Personally, if we follow approach #1 (make them look and smell as much like class members as possible) then I'm all for it in concept. It might even simplify many of the regular arguments I have about public properties and good architecture. :-) But only if we can cleanly stick to one definition of purpose, syntax, and semantics. Treating properties as a method implementation that can work like class members if you look at them from the right angle even though they're not class members and don't really work like them is a sure-fire way to confuse the hell out of people. PHP is complicated enough without introducing wave/particle duality. I agree Larry, the discussion is all over the place, but I think it is good because a lot of great ideas are coming up, and most of the bad ideas are getting flushed out. I think everyone needs to work through all of the possibilities before we come to a consensus on what is best. The basic Idea of a property, is making a getFoo() / setFoo($value) pair of methods look and act like a variable from the outside, and have an easily identifiable and simple to use syntax on the inside. The reason I originally focused so much around methods, is because properties literally are a pair of methods in C# (thats what they are compiled into). But PHP is another beast, and the challenges are different. As long as the original purpose of properties is not loss, whatever way we figure out is best to implement them is fine with me. - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 means
that it is a valid *possible* property, but does not currently hold any
value. This thinking is consistent with other languages. (I move
between
languages on a daily basis, so consistency is key to keeping my sanity!)
One certainly could implement it that way, but that would throw an E_NOTICE
if you're using class members and $account-beneficiary is not set. So
that
makes properties an incomplete drop-in for class members.
Hmm, I will have to contemplate that some more.
Thinking about properties further, actually, there's two other (related)
considerations that always give me grief when dealing with __get:
Reference returns and complex member variables.
If I want a reference to a class member, I can very easily do this:
$foo = $bar-baz;
If -baz is accessed via __get(), then that only works if __get() is
defined as function __get($var) to start with. That's another
encapsulation break.
If baz is a property, I would imagine:
$foo = $bar-baz;
would get a reference to the property itself, not a reference to the
return value of the set method. Therefore each call to the new
reference
would call either the get or set method, and would not operate on the
return value of the get. Just a note, C# does not support references to
properties, and yes, they break compatibility with variables by doing
that.
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 having a reference to a function, where you can
invoke the reference and it invokes the function. I say that as a
programming concept, not a PHP concept, because I am a bit fuzzy in the
function reference department of PHP.
(Making properties a free-form super-variable that are not bound to a
class is
a cool concept, but not at all what we're discussing here AFAIK.)
Right, that is not what this RFC is looking to achieve.
I imagine to get a reference to the return value of a property, you
would
do something like this:
$foo = ($bar-baz);
Similarly, the following does exactly what you'd expect with a normal
class member:
$foo-bar['baz']-narf = 'poink';
If $foo-bar is returned via __get(), though, then the above statement
executes but does not actually save anything... *unless* __get() was
defined to return by reference as above.
Ok I think I understand what you are saying. In this case, $foo-bar is
returning an array. You then access ['baz']-narf from that array.
Arrays are always passed by reference, are they not? If so, than the
above would work fine, no? Because $foo-bar would just be returning a
reference to some array, which you then modify.
Actually that's subtly wrong, which is the point I'm making. :-) If
$foo-bar
is a class member, then $foo-bar['baz'] dereferences from $foo to bar,
does
an array key lookup, finds an object, dereferences to the narf class
member,
and assigns poink to that. No new variables are ever created.
If $foo-bar is accessed via __get(), then $foo-bar *returns* an array by
value; the ['bar'] index of that new array is then accessed, we find an
object
there,that gets dereferenced to narf, and we assign 'poink' to that, in the
new array.
So is the solution then to make the set method return by reference? Or
does that just create more problems?
My question regarding properties here would be: There are subtle and
irritating differences between class members as __get() that make the
latter
not a true replacement for the former, especially when dealing with
arrays as
I've not found a way to work around those yet. What subtle and irritating
differences between class members and properties would we introduce, and
would
they be the same subtle and irritating inconsistencies or an entirely
new set
of subtle and irritating inconsistencies to have to deal with?
I would say, try our best to resolve all of the inconsistencies, and if we
cannot, then make sure they are the same inconsistencies that __get and
__set have, to be as least confusing as possible.
- Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 learn PHP. A good example is how == works differently in PHP than in other languages. In PHP, === works like == does everywhere else. (string)'0' == (int)0, for example is true in PHP, but false in most other languages. I have had countless conversations with PHP developers who claim the language is broken, because == does not work like they expect it to, after which I have to explain === to them. This is because PHP goes against the defacto standard. Maybe it would have been better if == and === had the opposite meaning, as to not squash the standard? You have got me there. = is assign == is equal value === is equal type and value At least on all the languages I've been using recently ... where is this a problem? In any language that does not have === it is like this: = is assign == is equal type and value That is where the confusion comes from. People do not expect 0 and 0 to be equal, because they are different types. javascript and C++ both do implicit type conversion (coercion) the same as PHP. You will have to prove that this is NOT the norm. There was a big debate a long time back on stopping implicit type conversion in C++ ... it did not get anywhere. What I am probably asking simply because I don't know is what language are you referring to as I've not come across any. If it's C# then that would explain it ... THAT was created by people who did not accept the consensus agreement in C/C++ ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 2 December 2010 13:51, presid...@basnetworks.net wrote:
2010/12/1 Richard Quadling rquadl...@gmail.com
On 1 December 2010 09:22, Stas Malyshev smalys...@sugarcrm.com 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, when isset is invoked, call the get method, and if it
returns null then isset() returns false, but otherwise returns true. That
was likely just a small oversight on Richard's part.
No, it was not an oversight.
Calling the getter() in response to isset() will probably result in a
change to the value of the property. For a property, isset() can and
only be interested in the last value of the property, not the next
value.
As I understand things, isset() performs 2 tests. First a check to see
if the variable exists and then to see if it has a value assigned.
For a property, the first part of that equation is fairly simple - the
property has to exist or not.
The second part though is not easy. A variable will not change value
in response to isset(), but, if isset() calls the getter(), then it
could and probably would. Calling isset() shouldn't alter anything.
Having isset() call the getter() and unset() call the setter() is fine
as long as the getter() and setter() know why they are being called.
If the developer needs to supply the last value - their choice - then
this could be implemented by caching the last value in a local scope
static. Completely encapsulated.
get($isset = false){
static $lastValue;
if (!$isset) {
// Generate the new value and assign it to $lastValue
}
return $lastValue;
}
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
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
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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. If people migrate to a major version of PHP 5 they should at least stop relying on PHP 4 features still valid thanks to BC consideration. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. This makes much sense! Correct me if I'm wrong, but isn't T_VAR on class members already an E_STRICT warning? I thought it was... --Larry Garfield -- 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
On Thu, Dec 2, 2010 at 17:07, la...@garfieldtech.com 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 --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. If people migrate to a major version of PHP 5 they should at least stop relying on PHP 4 features still valid thanks to BC consideration. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. This makes much sense! Correct me if I'm wrong, but isn't T_VAR on class members already an E_STRICT warning? I thought it was... --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php No, the warning was removed in PHP 5.1.3. Regards, Peter Beverloo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 having a reference to a function, where you can
invoke the reference and it invokes the function. I say that as a
programming concept, not a PHP concept, because I am a bit fuzzy in the
function reference department of PHP.
I don't believe PHP has function references per se. It has the ability
to call functions dynamically by either:
$function = 'foo';
$function();
// or
call_user_func[_array]('foo');
(The former is faster so preferred if you have a fixed number of variables.)
Functions are not first-class entities in PHP the way they are in, say,
Javascript so you can't pass them around, nor do you have function
pointers as you do in C. (My god those are a nightmare to code...)
PHP 5.3 introduced anonymous functions/closures, which seem at first
blush to be sort of like that. However, I believe the internal
implementation is done using objects and you can mimic that behavior on
an object using an interface, so really functions still don't have a
first-class status but are emulated using objects. (I'm sure one of the
compiler people can correct me if that's not entirely accurate.)
/tangent
Actually that's subtly wrong, which is the point I'm making. :-) If
$foo-bar
is a class member, then $foo-bar['baz'] dereferences from $foo to bar,
does
an array key lookup, finds an object, dereferences to the narf class
member,
and assigns poink to that. No new variables are ever created.
If $foo-bar is accessed via __get(), then $foo-bar *returns* an array by
value; the ['bar'] index of that new array is then accessed, we find an
object
there,that gets dereferenced to narf, and we assign 'poink' to that, in the
new array.
So is the solution then to make the set method return by reference? Or
does that just create more problems?
I'm not sure. I'm just pointing out that behaves like class members
is a substantially more complex scenario than it seems at first blush,
and we need to think through the implications of that and just how
closely we can emulate properties.
My question regarding properties here would be: There are subtle and
irritating differences between class members as __get() that make the
latter
not a true replacement for the former, especially when dealing with
arrays as
I've not found a way to work around those yet. What subtle and irritating
differences between class members and properties would we introduce, and
would
they be the same subtle and irritating inconsistencies or an entirely
new set
of subtle and irritating inconsistencies to have to deal with?
I would say, try our best to resolve all of the inconsistencies, and if we
cannot, then make sure they are the same inconsistencies that __get and
__set have, to be as least confusing as possible.
- Dennis
I agree that is a good guideline to follow.
It also provides a natural answer to the isset/unset question: If you
try to isset/unset a class member that doen't exist but __get() does,
what happens? (That may not always be the right answer, but it's a
comparison we should make.)
From another reply:
The basic Idea of a property, is making a getFoo() / setFoo($value) pair
of methods look and act like a variable from the outside, and have an
easily identifiable and simple to use syntax on the inside. The reason I
originally focused so much around methods, is because properties
literally
are a pair of methods in C# (thats what they are compiled into). But PHP
is another beast, and the challenges are different. As long as the
original purpose of properties is not loss, whatever way we figure out is
best to implement them is fine with me.
The original purpose being, specifically, smarter class members,
correct? (The internal syntax to define them we can bikeshed later;
determining the external syntax and semantics has to come first.)
--Larry Garfield
--
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
-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 parser to prevent conflicts, I therefore propose the
following RFC incl. patch to allow writing
class Foo {
public bar() {
echo Hello World;
}
}
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
johannes
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 to think that; I had no idea how you had an authoritative repo when everyone had a repo. Then I actually started working with Git, and the answer became obvious: You agree on one. You agree on a particular branch in a particular repo (eg, the one hosted on kernel.org / drupal.org / php.net) is the canonical branch, possibly restrict who can push to that (or not, but I think that would help PHP by having a release manager named early who can merge micro-branches), and document it. Git doesn't technologically force an answer on you; you get to define one socially. That actually works surprisingly well in practice in a functional project. (If PHP can't come to such an agreement in practice, that's a social problem, not a tool problem.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 wrong.
Right, what I was proposing didn't make sense. After digging through the
source, say we have:
class Foo {
public $a = 1;
protected $b = 2;
private $c = 3;
}
Currently this is:
O:3:Foo:3:{s:1:a;i:1;s:4:�*�b;i:2;s:6:�Foo�c;i:3;}
An alternative could be:
O:3:Foo:3:{s:1:a;i:1;*;s:4:b;i:2;_;s:6:c;i:3;}
Where *; is a marker for protected, _; is a marker for private
It would involve some trickery in ext/standard/var_unserializer.re :
*;{
/* prepend �*� to the next key so that we have zend_symtable_find(�*�b)
*/
}
_;{
/* prepend �Foo� to the next key so that we have
zend_symtable_find(�Foo�c) */
}
Just a thought if someone wants to refactor it / look into performance, I
believe that approach would support both:
O:3:Foo:3:{s:1:a;i:1;*;s:4:b;i:2;_;s:6:c;i:3;}
O:3:Foo:3:{s:1:a;i:1;s:4:�*�b;i:2;s:6:�Foo�c;i:3;}
--
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 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
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 christopher.jo...@oracle.com 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] 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 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 -- James Butler Sent from my iPhone On 2 Dec 2010, at 19:02, Christopher Joneschristopher.jo...@oracle.com 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
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 implemented in another way (see below).
First of all from a confusion point of view, PHP already has defined
property in a way that opposes your RFC's definition:
property_exists() checks for the existence of what you call a class
member. So, at least, it seems to me you would have to find new
terminology if you wanted to pursue this avenue of a new construct.
In my opinion, however, there should not be a new construct, and
property and class member should remain interchangeable
descriptions of the same class construct. I think we can do this and
still fix the encapsulation problem.
(Note: this is a long e-mail, and probably best represented in a new
RFC. I have also written this up more completely in the form of an
RFC, but I don't want to clutter up the wiki's RFC page unless other
people like this idea as well, so I'll add the RFC if it looks like it
will be useful).
For example, we could do:
class Time {
protected $time;
// note that $seconds, $minutes, and $hours are, in this
// implementation, dummies, since they will never hold
// a value, because their set functions only set the $time
// class member.
public $seconds;
public $minutes;
public $hours;
public function issetTime($name) isset($hours,$minutes,$seconds) {
return isset($this-time);
}
public function unsetTime($name) unset($hours,$minutes,$seconds) {
unset($this-time);
}
public function setTime($name, $value) set($hours,$minutes,$seconds) {
switch($name) {
case 'hours':
$this-time = $value * 3600;
break;
case 'minutes':
$this-time = $value * 60;
break;
case 'seconds':
$this-time = $value;
break;
}
$this-seconds = $seconds;
}
public function getTime($name) get($hours,$minutes,$seconds) {
switch($name) {
case 'hours':
return $this-time / 3600;
break;
case 'minutes':
return $this-time / 60;
break;
case 'seconds':
return $this-time;
break;
}
}
}
with this syntax, you could group the properties like above or, if you
preferred, you could have a different function for each property.
for read only (similar for write only), including the possibility of asymmetry:
class Time {
protected $time;
public $seconds;
public $minutes;
public $hours;
// ...
// now Time::$hours can only be set from inside the class / descendents
protected function setHours($name, $value) set($hours) {
$this-time = $value * 3600;
}
// but Time::$hours can still be retrieved from outside the class
public function getHours($name) get($hours) {
return $this-time / 3600;
}
}
for interfaces:
interface TimeClass {
public function setHours($name, $value) set($hours);
}
This has a number of benefits:
1. This acts like PHP, and also brings along features out of the box
(a) The new syntax mimics the form of the syntax of closures ($x =
function() use($a, $b) { // ... };), so it is somewhat familiar.
(b) The arguments of the isset, unset, getters and setters is
analogous to that in the __get and __set methods, so userland
implementation will be familiar.
(c) The getters and setters are still regular class methods, so they
can be called as methods as usual (subject to visibility, of course)
(d) Adds shades to the read-only and write-only concepts via
visibility modifiers!
(e) Isset / unset make sense now! E.g. that when unsetting $hours, we
actually want to unset the time in general. In fact, this is
preferred, because in the examples we've been looking at, the magic
is in grouping the three class members (seconds, minutes, hours),
and this implementation of isset and unset allow you to do just that
grouping, without having to write 3 isset and 3 unset functions, as
you would have to in the property definition.
(f) This allows for much more compact class definitions, as you don't
have to define getHours(), getMinutes(), getSeconds() individually if
you don't want to (although it allows you the flexibility to do that
if it's what you want).
(g) Inheritance works out of the box.
(h) Final keyword works out of the box.
(i) Documentation works out of the box (just do it as you do it now,
on the class members and the methods).
(j) Interfaces work.
(k) In the example above, the class could go ahead and set the
Time::$time class member directly without incurring the overhead of
the getter / setter functions!
2. Fixes the stated problems
(a) Adds the syntactic sugar to
Re: [PHP-DEV] Re: Hold off 5.4
On 2 Dec 2010, at 19:46, Christopher Jones christopher.jo...@oracle.com 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 Joneschristopher.jo...@oracle.com 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
[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: 36f7854304f9ecaa28d56f0eb163) The windows binaries will be available shortly at: http://windows.php.net/qa/ Since the first release candidate, we have not seen a large number of changes and and there are no show-stopper bugs for either version. At this point we both feel that the next logical step is the final release, which we would like to schedule a week from now. Given that this is the case, we would like to ask all developers to refrain making commits to the 5.3 and 5.2 branches, unless these constitue critical bug fixes, in which case please let Johannes and myself know about these fixes ahead of time. This way we can avoid last minute regressions, especially so for the 5.2.15 release, which is the final one in that series. Ilia Alshanetsky Johannes Schlüter PHP 5.2 Release Master PHP 5.3 Release Master -- 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 Thu, Dec 2, 2010 at 11:01 AM, Christopher Jones christopher.jo...@oracle.com 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. I think the unicode debacle will always give user's confusion, especially since there's many many PHP 6 books on bookshelves that speak of it. I think it's better to recognize what has happened with PHP 6, be honest to the community about what happened and why, and move on as best as we can. John Mertic jmer...@gmail.com | http://jmertic.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
