Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi: On 01 Dec 2010, at 01:31, presid...@basnetworks.net wrote: That is true for PHP variables. isset is basically saying does this variable exist, and unset is saying to get rid of it. This is also true for object properties - see magic methods. I don't see why you shouldn't be able to unset them - you can do that with regular properties... So what you imagine would happen if you call unset($foo-property) or isset($foo-property)? Its not a matter of consistency - Properties, as a cross-language concept are not meant to work that way. I tend to disagree. The need to be consistent inside of PHP has precedence over being consistent with other languages. You need to think of a property as a set 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. I think, it really is the other way around. Properties are meant to give the programmer the illusion that she is just having a field. That is abstraction. She does not care about implementation details. And that is the power of properties. isset() and unset() are perfectly fine in that context. And I do not see a problem to provide the standard semantics for them automatically, and let the programmer add isset/unset methods to the property as needed in exactly the same style as get/set. There is a good usecase for asking whether a property has been set, for instance to verify initialization. And, of course unset has also a useful meaning. It is about the value, and even so there are methods around a value, properties are meant to be values. There are definitely use-cases where that does not hold, but that is application specific. 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. 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-DEV] Project Management
While a little off topic, I feel that it is worth our having a discussion on project management. Source control, and the like ... Current discussion on 'git' highlights the fact that there is no clear solution to source control. The switch TO SVN was pushed through even though a few problems with that were then coming to light and now that move is probably questionable. Projects that had not jumped have now put that on hold since DVCS is obviously the next step, but none of the current solutions are ideal and each have as many minus as plus points. The real problem that I am finding is that all of these 'systems' work on the basis that we are handling source code which will then be compiled. Managing code that is not compiled becomes something of a mess especially when it would be nice to maintain file versions in those script files, and running a 'build' process to restore the tidy CVS type headers then makes things difficult between different DVCS systems. Many core DVCS developers simply do not understand that there is NOT a final binary distribution? Personally I've been getting into something of a mess trying to manage distributing PHP projects that are version controlled via hg since the only real way is to install hg on all the target machines ... something which is not really practical? I do get told to just use rsync to clone the files to other machines, which is a little impractical when the target machines are windows or don't have internet access. Fortunatly the CVS original is still running and back porting is sorting out the distribution problem! On top of that managing the release process to combine updates from other distributed code bases has already created the situation where there are 'sub-projects' which it is now difficult to integrate back with the original main project. I think we need to start a more integrated discussion on the whole of this project management process so that we can come up with a usable approach that works more generally for scripted language projects? Add IDE's like Eclipse and to some extent Zend framework, and there is another layer of complexity that further fragments the overall requirements. I've never had a problem with 'merging' simply because Eclipse/BC handles that and is currently allowing me to untangle the current niggles! -- 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 Tue, 2010-11-30 at 19:31 -0500, presid...@basnetworks.net wrote: 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. Even when a property does exist physically (by these methods) it might not exist logically. Missing that functionality is inconsistent with the languages. such an inconsistency would be enough reason for a -1000 vote :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Project Management
On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine les...@lsces.co.uk wrote: While a little off topic, I feel that it is worth our having a discussion on project management. Source control, and the like ... I agree. Current discussion on 'git' highlights the fact that there is no clear solution to source control. Really? There is no silver bullet, we just have to carefully inspect our possibilities, and decide: - do we really need DVCS, do we gain more than we lose? (I think most of the devs support the DVCS) - which DVCS would be a best fit for our specific needs. - what needs to be done for the transitional (I think we can use most of the experience, that we learned from the CVS - SVN migration) - what are the shortcomings of the selected DVCS, and how could we workaround/fix that The switch TO SVN was pushed through even though a few problems with that were then coming to light and now that move is probably questionable. could you explain that in more detail? I mean I can't think a possibility, when a CVS - SVN could be a bad idea, and didn't really heard bad things about the SVN from the devs (except when they compare it with DVCS). Projects that had not jumped have now put that on hold since DVCS is obviously the next step, but none of the current solutions are ideal and each have as many minus as plus points. what projects are you referring? I mean I think every open source project that I follow either use SVN, or already migrated to some DVCS. oh I forgot drupal: they are still using CVS, but the transition to Git is almost done. The real problem that I am finding is that all of these 'systems' work on the basis that we are handling source code which will then be compiled. Managing code that is not compiled becomes something of a mess especially when it would be nice to maintain file versions in those script files, and running a 'build' process to restore the tidy CVS type headers then makes things difficult between different DVCS systems. Many core DVCS developers simply do not understand that there is NOT a final binary distribution? Uhm, I think you lost me there. We are using version control for all of our non-compiled projects, and they working fine for us. Btw: we have build process for building the production version of our codebase (css/js combining, minifying, etc.), so we usually have a final distribution. But you are talking about non-binary stuff, the php core is compiled stuff, so what is the relevance of your sentences for that? Or you are talking about the difficulties of managing the pear/website stuff? Personally I've been getting into something of a mess trying to manage distributing PHP projects that are version controlled via hg since the only real way is to install hg on all the target machines ... something which is not really practical? I do get told to just use rsync to clone the files to other machines, which is a little impractical when the target machines are windows or don't have internet access. Fortunatly the CVS original is still running and back porting is sorting out the distribution problem! we do the following: we have a build machine, we checkout the code there, build the production version, and scp the files to the production server, set the permission, etc. test the staging site, and if everything is ok, then flip the staging to production. but I fail to understand, that how can you use the CVS, where you cant use the hg (the target machines are windows or don't have internet access.) I mean, you can install mercurial on windows, just as you can install SVN, and if the target machine doesn't have internet access, then I fail to see, that why should CVS work when mercurial shouldn't. On top of that managing the release process to combine updates from other distributed code bases has already created the situation where there are 'sub-projects' which it is now difficult to integrate back with the original main project. its not a problem with the tools, it is a problem with the project management: if you support multiple version, then supporting that takes more effort. one of my friend works for a navigation software company, and they have three major version, and HUNDREDS of supported devices, where the manufacturer asked for custom modifications, so they have a really hard time to manage that many branches, and that is a PITA to merge a bugfix everywhere (you have to find out, where is the bug present in the first place, then you can't be sure, that the patch will cleanly apply on every branch) and guess what: last time, when I asked, my friend told me, that they are using SVN. o_O I think we need to start a more integrated discussion on the whole of this project management process so that we can come up with a usable approach that works more generally for scripted language projects? which project are you referring to? I mean it could be useful to share info and experience about this, but I can't see why
Re: [PHP-DEV] Project Management
On Wed, Dec 1, 2010 at 1:12 AM, Lester Caine les...@lsces.co.uk wrote: While a little off topic, I feel that it is worth our having a discussion on project management. Source control, and the like ... Current discussion on 'git' highlights the fact that there is no clear solution to source control. The switch TO SVN was pushed through even though a few problems with that were then coming to light and now that move is probably questionable. Projects that had not jumped have now put that on hold since DVCS is obviously the next step, but none of the current solutions are ideal and each have as many minus as plus points. The real problem that I am finding is that all of these 'systems' work on the basis that we are handling source code which will then be compiled. Managing code that is not compiled becomes something of a mess especially when it would be nice to maintain file versions in those script files, and running a 'build' process to restore the tidy CVS type headers then makes things difficult between different DVCS systems. Many core DVCS developers simply do not understand that there is NOT a final binary distribution? Personally I've been getting into something of a mess trying to manage distributing PHP projects that are version controlled via hg since the only real way is to install hg on all the target machines ... something which is not really practical? I do get told to just use rsync to clone the files to other machines, which is a little impractical when the target machines are windows or don't have internet access. Fortunatly the CVS original is still running and back porting is sorting out the distribution problem! git archive cranks out a single file representing any commit in the repository, it can even format the archive w/ zip for the windows folks ;) On top of that managing the release process to combine updates from other distributed code bases has already created the situation where there are 'sub-projects' which it is now difficult to integrate back with the original main project. this happens all the time in centralized models as well, its just a matter of how often the code is being synchronized. in the case of dvcs, it's likely the peripheral project has not re-based or merged recently / frequently enough. and on top of that, the main project maintainers didn't see enough merit to ever sync up the peripheral project anyway.., so the onus would rest on the developers of the sub-project. not too unlike those good ol svn days at the office.., where someone wouldn't commit for weeks at a time, wouldn't even update very often, and then shocked to find out their code isn't merging completely w/ other new features and production support going on the whole time... if you think about it, having the projects disjoint like that is actually doing favor to the maintainers of the main project. less clutter in the 'official' repo. this is actually impossible to attain in svn, since all branches in svn are tied directly to the central server. I think we need to start a more integrated discussion on the whole of this project management process so that we can come up with a usable approach that works more generally for scripted language projects? Add IDE's like Eclipse and to some extent Zend framework, and there is another layer of complexity that further fragments the overall requirements. I've never had a problem with 'merging' simply because Eclipse/BC handles that and is currently allowing me to untangle the current niggles! graphical tools are nice, but I think the underpinnings are more important in deciding which is best for use. svn merging has performance bound tightly to the network meaning, if you aren't running the merge on the box actually hosting svn, you'd better be running it from a box physically close or w/ a really high bandwidth connection. of course dvcs lets you run fast merges no matter where you are and let the actual synchronization run after the merge is done, like while you're sleeping say :) also, the svn merge tracking is convoluted, there's a lot to have to know at the user level just to get around it. I've found it a lot easier to trust the merges from git than I ever did svn, and actually ran svn 1.5 for a while with their merge-tracking, which doesn't work correctly without proper user interaction read: --reintegrate .. I'm not a core php dev, but I have dealt w/ a lot of version control, and frankly moving to git from svn was an even better move than cvs to svn, no doubt about it. -nathan
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
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)? -- 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] RFC: C-sharp style property get/set syntax for PHP
Hi! Just to chime in on the subject of performance, here is how C# handles properties: PHP is not a compiled language and as such handling of properties, in particular, is radically different in PHP. For example, the property name in expression like $foo-$bar is known only in runtime. -- 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] RFC: C-sharp style property get/set syntax for PHP
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 ...
The behavior of unset() inside of a function can vary depending on
what type of variable you are attempting to destroy.
So, we already have differing behaviour based upon context. Attempting
to destroy a property should through a non fatal error.
One idea I had was to keep just the get/set property methods and add
to them an additional parameter ...
?php
public $seconds {
public set($value, $unset = False) {
if ($unset) {
// unset() has been called on the property.
// In this instance $value will be Null.
} else {
// set the property using the supplied $value.
}
},
public get($isset = False) {
if ($isset) {
// isset() has been called on the property.
// If the value is a non-destructive calculation then
maybe
returning the comparison of the result of the calculation to null.
} else {
// return the value for this property.
}
}
};
So,
isset($instance-property) would call $instance-property-get(True);
unset($instance-property) would call $instance-property-set(Null, True);
This keeps just the 2 property methods. It still allows isset/unset
and allows the developer the option of handling them.
--
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] Project Management
See other post as well Nathan Nobbe wrote: git archive cranks out a single file representing any commit in the repository, it can even format the archive w/ zip for the windows folks ;) YES but without any header updates to the files. Once unzipped you have no idea what version a file is, and that IS causing problems in the field. If you can replace the whole package of code, then it may not be a problem, but well structured pakcaged systems really need a little help when people can THEN mix and match. also, the svn merge tracking is convoluted, there's a lot to have to know at the user level just to get around it. I've found it a lot easier to trust the merges from git than I ever did svn, and actually ran svn 1.5 for a while with their merge-tracking, which doesn't work correctly without proper user interaction read: --reintegrate .. I'm not a core php dev, but I have dealt w/ a lot of version control, and frankly moving to git from svn was an even better move than cvs to svn, no doubt about it. I tried to work with git for over a month ... but my live customer base is on windows and git is simply not compatible ... hg is working nicely for me even talking into github, but managing several packages ( both binary and script ) that integrate into a single is something neither git or hg currently handle fully. One ends up switching between tools to keep things in sync, which is easy on Linux, but a pain on Windows. -- 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
2010/12/1 Eloy Bote Falcon eloyb...@gmail.com
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 ...
The behavior of unset() inside of a function can vary depending on
what type of variable you are attempting to destroy.
So, we already have differing behaviour based upon context. Attempting
to destroy a property should through a non fatal error.
One idea I had was to keep just the get/set property methods and add
to them an additional parameter ...
?php
public $seconds {
public set($value, $unset = False) {
if ($unset) {
// unset() has been called on the property.
// In this instance $value will be Null.
} else {
// set the property using the supplied $value.
}
},
public get($isset = False) {
if ($isset) {
// isset() has been called on the property.
// If the value is a non-destructive calculation
then maybe
returning the comparison of the result of the calculation to null.
} else {
// return the value for this property.
}
}
};
So,
isset($instance-property) would call $instance-property-get(True);
unset($instance-property) would call $instance-property-set(Null,
True);
This keeps just the 2 property methods. It still allows isset/unset
and allows the developer the option of handling them.
--
Richard Quadling
Twitter : EE : Zend
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.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.
Oops, the mail has been marked has spam because of some URI.
Regards.
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi! 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 I think the idea of new entity of the language looking exactly like old entity of the language but having different rules is kind of non-starter. One idea I had was to keep just the get/set property methods and add to them an additional parameter ... 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. -- 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] RFC: C-sharp style property get/set syntax for PHP
Hi Richard: On 01 Dec 2010, at 10:57, Richard Quadling wrote: 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. I tend to see that rather different. Properties are not about methods, properties as in C# are about abstracting from the actual realization of how the state is represented internally that is exposed by a property. Thus, properties like proposed here should be used to provide the illusion of having normal class variables. And in that scenario it makes sense to talk about the value the property represents and not the fact that there are methods. So, from my point of view isset/unset have perfectly valid semantics on many of the usual cases. Even so, I agree, there are cases where that is not so, but in those cases isset/unset could be specialize like set/get. 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
Re: [PHP-DEV] Project Management
Ferenc Kovacs wrote: On Wed, Dec 1, 2010 at 9:12 AM, Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk wrote: While a little off topic, I feel that it is worth our having a discussion on project management. Source control, and the like ... I agree. Current discussion on 'git' highlights the fact that there is no clear solution to source control. Really? There is no silver bullet, we just have to carefully inspect our possibilities, and decide: - do we really need DVCS, do we gain more than we lose? (I think most of the devs support the DVCS) - which DVCS would be a best fit for our specific needs. - what needs to be done for the transitional (I think we can use most of the experience, that we learned from the CVS - SVN migration) - what are the shortcomings of the selected DVCS, and how could we workaround/fix that Yep ... those are the basic questions ... git, hg, brz or 'another' Since we do have SVN now does the MASTER source need to change. We hould be able to do our own thing locally on your prefered DVCS if that is your choice, but mirroring from SVN ... if the problem of git-svn and the like can be addressed! The switch TO SVN was pushed through even though a few problems with that were then coming to light and now that move is probably questionable. could you explain that in more detail? I mean I can't think a possibility, when a CVS - SVN could be a bad idea, and didn't really heard bad things about the SVN from the devs (except when they compare it with DVCS). There were a few comments on the 'git anybody' thread, but cloaning CVS to a DVCS seems to be less hassle than mirroring an SVN master? Projects that had not jumped have now put that on hold since DVCS is obviously the next step, but none of the current solutions are ideal and each have as many minus as plus points. what projects are you referring? I mean I think every open source project that I follow either use SVN, or already migrated to some DVCS. oh I forgot drupal: they are still using CVS, but the transition to Git is almost done. Drupal was my first thought and I'm fighting the mess on bitweaver at the moment. Other projects I've been half playing with seem to be in the same state of flux ... The real problem that I am finding is that all of these 'systems' work on the basis that we are handling source code which will then be compiled. Managing code that is not compiled becomes something of a mess especially when it would be nice to maintain file versions in those script files, and running a 'build' process to restore the tidy CVS type headers then makes things difficult between different DVCS systems. Many core DVCS developers simply do not understand that there is NOT a final binary distribution? Uhm, I think you lost me there. We are using version control for all of our non-compiled projects, and they working fine for us. Btw: we have build process for building the production version of our codebase (css/js combining, minifying, etc.), so we usually have a final distribution. But you are talking about non-binary stuff, the php core is compiled stuff, so what is the relevance of your sentences for that? Or you are talking about the difficulties of managing the pear/website stuff? Exactly ... while the base discussion here is for the compiled modules, a decision there should not be at the expense of being able to support the website/pear stuff as well. Personally I've been getting into something of a mess trying to manage distributing PHP projects that are version controlled via hg since the only real way is to install hg on all the target machines ... something which is not really practical? I do get told to just use rsync to clone the files to other machines, which is a little impractical when the target machines are windows or don't have internet access. Fortunatly the CVS original is still running and back porting is sorting out the distribution problem! we do the following: we have a build machine, we checkout the code there, build the production version, and scp the files to the production server, set the permission, etc. test the staging site, and if everything is ok, then flip the staging to production. but I fail to understand, that how can you use the CVS, where you cant use the hg (the target machines are windows or don't have internet access.) I mean, you can install mercurial on windows, just as you can install SVN, and if the target machine doesn't have internet access, then I fail to see, that why should CVS work when mercurial shouldn't. Again this is more website than binary files. And not just a PHP problem, but I've had great trouble with fixing Python code in hg and syncing those changes with submissions from others. The CVS header is an ideal way to be able to check the version of a file in use. SVN can do the same thing, but the tool guys don't seem to
Re: [PHP-DEV] Project Management
On 01/12/10 10:13, Lester Caine wrote: See other post as well Nathan Nobbe wrote: git archive cranks out a single file representing any commit in the repository, it can even format the archive w/ zip for the windows folks ;) YES but without any header updates to the files. Once unzipped you have no idea what version a file is, and that IS causing problems in the field. If you can replace the whole package of code, then it may not be a problem, but well structured pakcaged systems really need a little help when people can THEN mix and match. I can't speak for other DVCS systems, but you could use a git smudge filter to add any sort of source-control headers if you really, really want to: http://chillibear.org/2010/04/git-and-cvs-like-keyword-expansion-idents.html D
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
On 1 December 2010 10:23, Eloy Bote Falcon eloyb...@gmail.com wrote:
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 ...
The behavior of unset() inside of a function can vary depending on
what type of variable you are attempting to destroy.
So, we already have differing behaviour based upon context. Attempting
to destroy a property should through a non fatal error.
One idea I had was to keep just the get/set property methods and add
to them an additional parameter ...
?php
public $seconds {
public set($value, $unset = False) {
if ($unset) {
// unset() has been called on the property.
// In this instance $value will be Null.
} else {
// set the property using the supplied $value.
}
},
public get($isset = False) {
if ($isset) {
// isset() has been called on the property.
// If the value is a non-destructive calculation
then maybe
returning the comparison of the result of the calculation to null.
} else {
// return the value for this property.
}
}
};
So,
isset($instance-property) would call $instance-property-get(True);
unset($instance-property) would call $instance-property-set(Null,
True);
This keeps just the 2 property methods. It still allows isset/unset
and allows the developer the option of handling them.
--
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
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 properties are abstractions to methods, then they don't serve a purpose.
If properties are wrappers for locally cached values then they
isset/unset is feasible.
If properties are to ... provide the illusion of having normal class
variables ... ... then it is undefined if there is a real value held
anywhere.
You do not want isset() to have to get() the value of the property as
the getter may be getting the data from (for example) a DB, SOAP
request, etc. Getting the data is not as simple as just returning a
local value.
I think isset() and unset() for properties is different to that for
variables. Either isset() and unset() generate errors when called on
properties, or, with an amendment to the syntax, isset() and unset()
are passed to the setter and getter (if they exist) to allow the
developer of the property to decide what to return.
--
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: C-sharp style property get/set syntax for PHP
On 1 December 2010 10:38, Stas Malyshev smalys...@sugarcrm.com wrote:
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).
--
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] Project Management
Dave Ingram wrote: git archive cranks out a single file representing any commit in the repository, it can even format the archive w/ zip for the windows folks ;) YES but without any header updates to the files. Once unzipped you have no idea what version a file is, and that IS causing problems in the field. If you can replace the whole package of code, then it may not be a problem, but well structured pakcaged systems really need a little help when people can THEN mix and match. I can't speak for other DVCS systems, but you could use a git smudge filter to add any sort of source-control headers if you really, really want to: http://chillibear.org/2010/04/git-and-cvs-like-keyword-expansion-idents.html Now that is one I have not seen, but outlines the reasons for wanting it nicely. It does highlight another part of this jigsaw ... need ruby running as well as python and php ;) I know that we are not going to get a nice clean PHP solution, but the spread of languages needed just seems to be growing just to add DVCS? -- 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
Hi! No. The prototype of all setters would be the same. As would the prototype of all getters. But we'd have two sets of properties - one handled by __get/__isset, another - by get($isset). Not a good idea. -- 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] RFC: C-sharp style property get/set syntax for PHP
On 1 December 2010 12:30, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! No. The prototype of all setters would be the same. As would the prototype of all getters. But we'd have two sets of properties - one handled by __get/__isset, another - by get($isset). Not a good idea. So, should properties isset/unset go via the magic methods? With properties, there would be the duplication anyway (__get()/get() and __set()/set()). Either way, only the property knows what should happen when an isset() or unset() is called against it. It is for that reason that I think the property should handle it. __get, __set, __isset and __unset are for undefined class members. Not properties. From the user of the class, completely invisible. Having more than 1 way to skin the cat is pretty much de rigueur for PHP. -- 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: C-sharp style property get/set syntax for PHP
Hi Davey,
Object properties (or members, classic -var, not this proposed syntax)
CURRENTLY, work this way:
php -r 'class foo { public $bar; } $foo = new foo();
var_dump(isset($foo-bar));'
bool(false)
This is because you are confusing PHP's isset() with a property_exists().
Is set. Is the variable (or member/property)
set to a value?
I did not know of property_exists(), very interesting!
In this case, both isset() and unset() work with the property get/set you
are proposing. Imagine:
$results = $db-query('SELECT SQL_CALC_FOUND_ROWS * FROM some_table WHERE
foo = 'bar');
if (isset($results-count)) {
foreach ($results-getResult() as $result) {
// Do something
}
}
where isset() would hit:
protected property count {
isset {
$result = $this-execute('SELECT FOUND_ROWS()');
$this-count = $result-getColumn();
if ($this-count == 0) {
return false;
}
return false;
}
}
Not an ideal example, but it gives you an IDEA off the top of my head of a
way to take advantage of it
Well, I understand the concept and how it would work, but I just don't
think its logical. In my mind, being able to make a property appear to
disappear makes as much sense as making a class method appear to
disappear. This is absolutely no good for inheritance for one thing.
The __isset method makes perfect sense, because all variables handled with
__get and __set don't truly exist. They are not actually defined in the
class, they are just fake class members, whose data comes from somewhere
else - maybe an array. So __isset is there to say which fake member
names do and don't exist.
But when defined, a property, like a method, shouldn't be able to just
disappear. It is a specific definition and should never appear to be
missing. If you need a class member that can be unset, you should be
using __isset __get and __set, because that is exactly what those are
meant for.
My feelings are that a property foo should behave exactly like a
getFoo() and setFoo($value) pair of methods. You can always call these
methods, and never worry that you will get a method not set error. When
you call getFoo() you are always guaranteed to get something, even if it
is simply NULL.
Maybe I am missing your point? But it does not make logical sense to me,
the way you suggest.
Also, would adding isset not make properties much slower? Calling
$object-foo would first have to call and process the isset method to
determine if it is set, then after getting true from isset, it would be
able to call get. And what happens if there is no isset? Is it just
always guaranteed to be set then?
- 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
That is true for PHP variables. isset is basically saying does this variable exist, and unset is saying to get rid of it. This is also true for object properties - see magic methods. I don't see why you shouldn't be able to unset them - you can do that with regular properties... So what you imagine would happen if you call unset($foo-property) or isset($foo-property)? Its not a matter of consistency - Properties, as a cross-language concept are not meant to work that way. I tend to disagree. The need to be consistent inside of PHP has precedence over being consistent with other languages. 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. You need to think of a property as a set 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. I think, it really is the other way around. Properties are meant to give the programmer the illusion that she is just having a field. That is abstraction. She does not care about implementation details. And that is the power of properties. isset() and unset() are perfectly fine in that context. And I do not see a problem to provide the standard semantics for them automatically, and let the programmer add isset/unset methods to the property as needed in exactly the same style as get/set. There is a good usecase for asking whether a property has been set, for instance to verify initialization. And, of course unset has also a useful meaning. It is about the value, and even so there are methods around a value, properties are meant to be values. There are definitely use-cases where that does not hold, but that is application specific. 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. - 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
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? 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? 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? Because properties are only meant to be a pretty syntax for a get/set method. Thats it! I don't know of any other special behaviour in any other language that lets you hide properties or anything else like 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. Sorry, from your answer I don't understand - what happens when you call isset($foo-property) and unset($foo-property)? You make a good point. If we can't unset a property, than we lose consistency with regular variables which I guess ruins the point of properties. - 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
Just to chime in on the subject of performance, here is how C# handles properties: PHP is not a compiled language and as such handling of properties, in particular, is radically different in PHP. For example, the property name in expression like $foo-$bar is known only in runtime. Yes, of course. Like I say, that is just how it works in C#, I make no claims about how it would or should work in PHP. I was just hoping that comparisons to C# would help to inform the discussion. However, I would imagine that the get/set within a property would be interpreted as methods in PHP irregardless, so apart from checking to see if a class member is a property, and finding its get/set method to call, would the performance not be exactly that of a method call? - 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
public property Hours read getHours write setHours; I actually like that, though I think we should support the whole existing semantics, i.e. get/set/isset/unset. And probably keep the names, so we don't call the same thing both read and get. This doesn't make sense. To call isset() on a property, would be to ask if the property itself exists. But once defined, a property always exists (think of methods, for example). (Sorry for sending again Stas, I forgot to reply all) - Dennis True, but if part of the intent (as noted in a previous email) is to provide a mechanism that looks to the outside world like a class member, and therefore one can switch between the two without breaking an API, then isset/unset should have some sort of useful meaning. This is the exact issue Stas touched upon earlier, and you are both absolutely right. If isset/unset are not supported, than class variables and properties cannot truly be interchangeable. However, my issue is this: If get/set/isset/unset are all supported as methods in a property, I do not think it wise to require isset/unset to be created - they should be optional, for the few times that they would be useful. However, the question is, if you do not define isset/unset, then what do they do? isset could always return true, but what about unset? Does it just do nothing? That does not make sense from the perspective of a user of the class. Maybe if you call unset, than isset now returns false. Then once you call set again, isset now returns true? That would be consistent with how variables work... - 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! 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 Not everywhere. Perl has the same rules, for example. 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? There's no such standard. PHP works differently than the language you knew before, that's it. If it worked the same, it would be the same language. Because properties are only meant to be a pretty syntax for a get/set method. Thats it! I don't know of any other special behaviour in any other language that lets you hide properties or anything else like that. If that's it, we probably don't need them. They would just hide what happens in the code and confuse the user, which would not know what $a-foo means - would it work according to class attribute rules or class method rules? I think, however, this syntax might be useful - for example, Zend Framework does a lot of property/method linking, some other frameworks do that too, and individual methods might be better than catch-all in this case. But that requires consistency. 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. You make a good point. If we can't unset a property, than we lose consistency with regular variables which I guess ruins the point of properties. It doesn't have to - if we can find a consistent concept of how to do it. But we need to think about 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
Re: [PHP-DEV] Project Management
On 12/01/10 12:21, Lester Caine wrote: Dave Ingram wrote: git archive cranks out a single file representing any commit in the repository, it can even format the archive w/ zip for the windows folks ;) YES but without any header updates to the files. Once unzipped you have no idea what version a file is, and that IS causing problems in the field. If you can replace the whole package of code, then it may not be a problem, but well structured pakcaged systems really need a little help when people can THEN mix and match. I can't speak for other DVCS systems, but you could use a git smudge filter to add any sort of source-control headers if you really, really want to: http://chillibear.org/2010/04/git-and-cvs-like-keyword-expansion-idents.html Now that is one I have not seen, but outlines the reasons for wanting it nicely. It does highlight another part of this jigsaw ... need ruby running as well as python and php ;) You don't have to write the filter in Ruby -- that was just his choice. You could use shellscript, PHP, or even C if you really wanted. D -- 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 01 Dec 2010, at 14:10, presid...@basnetworks.net wrote: 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. 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. 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
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hello,
You are missing the point in PHP in that case. Because PHP is dynamic
scripting language, public properties can be added and removed in the
object on the fly. That's why there is isset and unset that works on
object properties. Consider ActiveRecord, DataMappers, ORM, etc. They
use that 100% to their advantage - I haven't yet seen a model witch
defines all the properties in PHP code - mostly it takes table columns
from DB and add these properties in dynamic way.
That's why it isn't so straight forward of adding properties like you
propose.
I think you are correct, and I am beginning to see the light on this
issue. In order for a property to be 100% compatible with regular
variables, it needs to work properly with isset and unset.
P.S. By the way, maybe I haven't being doing some really crazy stuff
on PHP, but I rarely define getters and setters in my classes that do
something except $this-val = $val and return $this-val. Well,
honestly I haven't worked on some stuff developed by more that 6
programmers too (Latvia is a small county - no major epic projects at
all), but still I think my point is valid.
Properties have a variety of uses. One use is to make a read-only value
that can later have a set method added in a child class. This is not
possible with the readonly keyword. You can also provide different
visibilities for the get and set, as well as marking them final or
abstract individually.
You can use properties to provide simple validation. For example:
class TimePeriod
{
private $_hours;
/// Hours must be between 1-12
public property Hours
{
get { return $this-_hours; }
set
{
if ($value 1 || $value 12)
{
throw new Exception(Hours must be between 1-12);
}
$this-_hours = $value;
}
}
};
You can also use properties to dynamically generate a value, such as in
one of the examples in the RFC:
class TimePeriod
{
private $seconds;
public property Hours
{
get { return $this-seconds / 3600; }
}
public property Minutes
{
get { return $this-seconds / 60; }
}
};
Here is some additional reading on C# properties from MSDN:
http://msdn.microsoft.com/en-us/library/ms229054.aspx
http://msdn.microsoft.com/en-us/library/ms229006.aspx
- 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? Also isset() makes perfect sense when you have NULL values coming from a database. unset then kicks a NULL back to the database if updating. The varable exists but has a NULL value ... -- 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?
hi, I think we have enough feedback about this topic. We will come back with a detailed proposal explaining how it could be done, which tools, etc. Thanks for the constructive replies, Cheers, On Tue, Nov 30, 2010 at 9:41 PM, dukeofgaming dukeofgam...@gmail.com wrote: Hi, I've never participated on the lists, but this was a topic I could just not look away from. My take on this is that it all boils down to the statistics of the developers and contributors, as Gwynne said, there is really no much merit on technical aspects of the tools... but rather how the community plans to use other tools around it. My preferred DVCS is mercurial due to its portability (no messing with bash consoles in Windows, using it is the same for all platforms) and the fact that I use Netbeans as my main IDE and it comes by default with the mercurial plugin (the Netbeans project uses mercurial). I also like mercurial because Bitbucket.org is comparable enough to github, and more generous with its free accounts (free private repositories and unlimited space). I also like git, but I stick with mercurial. I have never used bazaar... and I have never used svn for team development, fortunately =). Regards, David On Tue, Nov 30, 2010 at 11:21 AM, Lester Caine les...@lsces.co.uk wrote: Gwynne Raskind wrote: *Googles.* *Reads.* Well... dang. Go Wez!! Magic just what I was looking for as well. -- 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 -- 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
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi Larry,
First of all, I have generally found the Bean-style getter/setter
approach to
be a sign of poor encapsulation to begin with. You shouldn't be
mucking
with
internal elements of an object in the first place, period. More
details on
that here:
http://www.garfieldtech.com/blog/property-visibility
Interesting post, although I can't say I agree with your views. Your
post
leaves me wondering how the user is expected to get or give data to a
class (for example, if I'm not supposed to do $customer-name or
$customer-getName(), how do I get the customers name?). Additionally,
you
are forgetting the real power of properties, which is the ability to
generate a get value, and process a set value, because get/set are
methods. Properties are hardly just an indirection layer around an
underlying piece of data.
The idea of a -getName() method for retrieving a person's name is fine.
My point there is that any assumption that it corresponds to a -name
class member (as Bean definitions require) is invalid on its face. (The
context there is a lengthy ongoing debate regarding the use of public
vs. protected class members, with my basic point being that class
members are an implementation detail and if you care about them in the
first place then you have a bug. Yes, it's a deliberately stringent
position.)
Right, I think I understand the whole Bean thing now. Its just a
struct, but has get/set methods instead of public properties? In that
case, that is rather silly. A get/set method should not be required to
correspond to any underlying value. A get could even return a constant,
inline value for that matter. It shouldn't matter what a get returns, as
long as it returns something!
I do not agree with class members are an implementation detail. I would
say private/protected members/methods are an implementation detail,
which is true no matter how you slice it. There are perfectly valid
reasons for exposing public class members. Heck I make classes that are
just a set of public class members, and do not even have methods. This is
what a struct is in C, C++ and C#. Its just a storage container (like a
bean in java, but without silly methods for every class member). Arguably
an array could be used for this, but an array has less structure and is
not properly suited for a well-defined type.
What I'm seeing here is that whether properties are intended as an
indirection layer for class members (eg, a more robust __get/__set) or
not is a fuzzy question. On the one hand they are (since the goal of
the syntax is to make it irrelevant to the caller which is happening),
but on the other they're supposed to be something different that can do
all kinds of on the fly behavior.
Properties can be thought of as a __get/__set that only handle a single
class member name each. They are for single members, while __get/__set
is generically for all members. I can see how you would call
__get/__set and indirection layer because, since you are handling the
values generically, doing anything other than indirection is too
complicated. But when you are writing accessors for a single defined
member, its easier to be more robust - you can do anything you could do in
a normal method.
- Which also brings up an interesting question:
class Foo {
public $a = 1;
protected $b = 2;
public property $a { get { return 3; } }
public property $b { get { return 4; } }
}
$f = new Foo();
print $f-a . PHP_EOL; // Does this print 1 or 3?
print $f-b . PHP_EOL; // Does this print 2 or 4, or error?
Both of those throw an error. Properties and variables share the same
namespace, so you cannot define a property and variable with the same
name.
Is this consistent with methods? Do those share a namespace, too? (I
don't actually recall off the top of my head.)
methods and variables have their own namespaces. This is because they are
called differently:
// variable $a
print $f-a;
// method a()
print $f-a();
But variables and properties would be called the same way (both $f-a;).
Because of this, they need to share the same namespace in order to avoid
ambiguity. This is in fact a feature of properties, because this way an
existing variable can later be replaced with a property, and all calling
code will continue to work (or at least will compile).
This is what I would imagine seeing, and would compile:
class Foo {
private $_a = 1;
protected $_b = 2;
public property $a { get { return 3; } }
public property $b { get { return 4; } }
}
As you can see, there is no conflict or confusion this way.
True, although for the record I have always detested the underscore
prefix on variables as a difficult to read hack. :-)
To be honest, I also detest the underscore prefix. In C# we use camel
case for public and pascal case for private, but because PHP is
case-insensitive, that (very unfortunately) is not possible.
C# example:
class Foo {
private
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
Hi Larry,
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
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.
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.
Consistency with other languages must also be balanced against
consistency within PHP. Both are important.
Class members and both existing class-member-ish mechanisms (__magic and
ArrayAccess) have the concept of isset/unset. A third class-member-ish
(syntactically speaking) mechanism will be expected to have the same set
of primitives. To not have them will be a major language WTF, because
to a normal user of an object they *look* like class members, not
methods, they *taste* like class members, not methods, so they should
*act* like class members, not methods.
Basically, properties can only be considered a drop-in replacement for
class members (as you've stated, correctly, is one of the potential big
wins for them) if they fully emulate their behavior. If they do not,
then it is incorrect to say that they can be swapped in for a class
member without changing an API.
Yes, you are correct, if they are to be a full drop-in replacement, they
must handle isset/unset as expected. This is something I had not thought
of earlier.
__isset() is a whole different matter, without it we would have to
assume
that every possible member name either exists or does not exist. This
is
because __isset can handle ANY member name.
Properties are bound to a single member name, therefore, they always
exist, unless you were to physically remove that property from the
class,
which, like methods, that is not possible.
No, but it can be easily emulated.
Actually, I can even think of a concrete use case. Suppose I have an
object that acts as a facade for a remote object over SOAP, REST, or
whatever. It is using properties to represent attributes of a remote,
say, insurance account. I want to know if a beneficiary has been set on
the account. The most straightforward way to do so is
if (isset($account-beneficiary)) {
print $account-beneficiary-name;
}
If we are implementing such logic via __get(), we can do exactly that.
If we are implementing it via properties, we should still be able to.
Forcing the user to know that he needs to do it this way instead, but
only if we're using properties rather than __get():
if ($account-hasBeneficiary()) {
print $account-beneficiary-name;
}
is violating the principle of encapsulation as it means the user needs
to know which of the three forms of $account-beneficiary happens to be
in use.
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!)
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.
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
Re: [PHP-DEV] git anyone?
On 2010-12-01, Pierre Joye pierre@gmail.com wrote: hi, I think we have enough feedback about this topic. We will come back with a detailed proposal explaining how it could be done, which tools, etc. I think it would be good to have people willing to help out with evaluating certain DVCS. In particular we need someone for BZR to put together a good RFC. I'll probably help evaluating Git and Mercurial. -- 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 Sun, 28 Nov 2010, presid...@basnetworks.net wrote: Link to the RFC: http://wiki.php.net/rfc/propertygetsetsyntax -1 Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote: On 2010-12-01, Pierre Joye pierre@gmail.com wrote: hi, I think we have enough feedback about this topic. We will come back with a detailed proposal explaining how it could be done, which tools, etc. I think it would be good to have people willing to help out with evaluating certain DVCS. In particular we need someone for BZR to put together a good RFC. I'll probably help evaluating Git and Mercurial. An evaluation requires a clear set of goals first. Like: Why change? What is broken? What can be improved? What are existing requirements? Once that is done one can start evaluating specific tools. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On 01.12.2010 16:16, Johannes Schlüter wrote: On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote: On 2010-12-01, Pierre Joye pierre@gmail.com wrote: hi, I think we have enough feedback about this topic. We will come back with a detailed proposal explaining how it could be done, which tools, etc. I think it would be good to have people willing to help out with evaluating certain DVCS. In particular we need someone for BZR to put together a good RFC. I'll probably help evaluating Git and Mercurial. An evaluation requires a clear set of goals first. Like: Why change? What is broken? What can be improved? What are existing requirements? Once that is done one can start evaluating specific tools. yes, I'm aware of that, but it make sense to ask for people support right during a discussion. So we can get together and discuss the goals. johannes -- 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 2010-12-01, Arvids Godjuks arvids.godj...@gmail.com wrote: You are missing the point in PHP in that case. Because PHP is dynamic scripting language, public properties can be added and removed in the object on the fly. That's why there is isset and unset that works on object properties. Consider ActiveRecord, DataMappers, ORM, etc. They use that 100% to their advantage - I haven't yet seen a model witch defines all the properties in PHP code - mostly it takes table columns from DB and add these properties in dynamic way. That's why it isn't so straight forward of adding properties like you propose. The new generation of ORMs and data mappers are actually using plain old PHP objects -- which means you can define the properties up-front in your code, and the mappers then inject from whatever data source they pull from. They're *not* defining properties on the fly. (Original iterations of ActiveRecord and ORMs *were* -- but newer ones are typically not.) P.S. By the way, maybe I haven't being doing some really crazy stuff on PHP, but I rarely define getters and setters in my classes that do something except $this-val = $val and return $this-val. Well, honestly I haven't worked on some stuff developed by more that 6 programmers too (Latvia is a small county - no major epic projects at all), but still I think my point is valid. I think it *used* to be... but is getting less so with modern PHP developers, based on what I'm observing in a number of communities (ZF, Symfony, even Lithium...). 2010/12/1 presid...@basnetworks.net: public property Hours read getHours write setHours; I actually like that, though I think we should support the whole existing semantics, i.e. get/set/isset/unset. And probably keep the names, so we don't call the same thing both read and get. This doesn't make sense. To call isset() on a property, would be to ask if the property itself exists. But once defined, a property always exists (think of methods, for example). (Sorry for sending again Stas, I forgot to reply all) - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Dec 1, 2010, at 5:16 PM, Johannes Schlüter wrote: On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote: On 2010-12-01, Pierre Joye pierre@gmail.com wrote: hi, I think we have enough feedback about this topic. We will come back with a detailed proposal explaining how it could be done, which tools, etc. I think it would be good to have people willing to help out with evaluating certain DVCS. In particular we need someone for BZR to put together a good RFC. I'll probably help evaluating Git and Mercurial. An evaluation requires a clear set of goals first. Like: Why change? What is broken? What can be improved? What are existing requirements? Once that is done one can start evaluating specific tools. Instead of doing this, how about concentrate in actual work for the next release? And IMO, there's nothing broken that needs fixing or changing to some DVCS since SVN works just fine.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
thanks for remember me the obvious questions, anything else to add or? 2010/12/1 Johannes Schlüter johan...@schlueters.de: On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote: On 2010-12-01, Pierre Joye pierre@gmail.com wrote: hi, I think we have enough feedback about this topic. We will come back with a detailed proposal explaining how it could be done, which tools, etc. I think it would be good to have people willing to help out with evaluating certain DVCS. In particular we need someone for BZR to put together a good RFC. I'll probably help evaluating Git and Mercurial. An evaluation requires a clear set of goals first. Like: Why change? What is broken? What can be improved? What are existing requirements? Once that is done one can start evaluating specific tools. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
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 2010/12/1 Johannes Schlüter johan...@schlueters.de On Wed, 2010-12-01 at 10:01 -0500, David Soria Parra wrote: On 2010-12-01, Pierre Joye pierre@gmail.com wrote: hi, I think we have enough feedback about this topic. We will come back with a detailed proposal explaining how it could be done, which tools, etc. I think it would be good to have people willing to help out with evaluating certain DVCS. In particular we need someone for BZR to put together a good RFC. I'll probably help evaluating Git and Mercurial. An evaluation requires a clear set of goals first. Like: Why change? What is broken? What can be improved? What are existing requirements? Once that is done one can start evaluating specific tools. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
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] RFC: C-sharp style property get/set syntax for PHP
On Wednesday, December 01, 2010 8:28:19 am presid...@basnetworks.net wrote: Is this consistent with methods? Do those share a namespace, too? (I don't actually recall off the top of my head.) methods and variables have their own namespaces. This is because they are called differently: // variable $a print $f-a; // method a() print $f-a(); But variables and properties would be called the same way (both $f-a;). Because of this, they need to share the same namespace in order to avoid ambiguity. This is in fact a feature of properties, because this way an existing variable can later be replaced with a property, and all calling code will continue to work (or at least will compile). 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. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
