Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())
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. But I'm +1 for improving the serialize() speed, I had problems recently with it, and igbinary came to save me as well :) Julien.Pauli On Sun, Nov 28, 2010 at 5:15 PM, Jonathan Bond-Caron jbo...@openmv.com wrote: On Thu Nov 25 12:47 PM, Andi Gutmans wrote: I know there have been some high-end apps that have benefited from some custom serializers, etc... (typically platform dependent). I wonder if people here think improvements in these areas would move the needle for the majority of mainstream apps or not. Like people have mentioned, improving (un)serialize speed would be a huge benefit, especially for caching data sets or large objects. From experience, it would seem valuable to have: 1) serialize_text($var) The existing serialize() minus the NULL bytes on private properties. It has been a source problems for developers serializing an object with private properties and storing it in a database (the string may get cutoff). I'm not sure why there's a NULL byte in 'zend_mangle_property_name', instead the char _ could be used to mark a private property in the serialized text. The unserialize could be BC compatible accepting both NULL and _ around a private property. 2) serialize_binary($var) An efficient and compact serialization using techniques from igbinary. A potential problem with igbinary I've noticed is it packs a double as a 64 bit integer. That could be a problem if you serialize on a platform that has an IEEE 754 binary representation and unserialize on a non-IEEE platform but I don't know if php compiles on architectures that are non-IEEE. It could also be interesting to pack integers as varints: http://code.google.com/apis/protocolbuffers/docs/encoding.html#varints http://protobuf-c.googlecode.com/svn/trunk/src/google/protobuf-c/protobuf-c. c That's most likely slower though then what igbinary does with integers -- 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] Re: [PHP-WEBMASTER] Hi
Hi. it was rejected for inclusion that time, but maybe it could be a good idea to try to propose it again. this kind of discussion should be taken place on internals@lists.php.net , I've just cc'ed it. for writing an RFC, you should register on the wiki: http://wiki.php.net/ and ask karma for the rfc wikispace (usually Philip Olson sends an email to every new wiki user, and ask what kind of karma is needed) After that, you can write the rfc, and post an email to the internals: request for comments about the idea, and usually people start commenting, and voting, and so. ps: it's preferred, to use bottom-posting on the php mailing lists. On Tue, Nov 30, 2010 at 9:22 AM, Loon, Reinier van reinier.van.l...@gmail.com wrote: Okay, thanks. That patch would work just fine for me. Why don't we include it in the next PHP release? I mean, there is no point in a patch. Hosters that run our software will not patch their PHP installation. So, we need it in the release. How can I respond on the mail list? Cheers, Reinier 2010/11/29 Ferenc Kovacs i...@tyrael.hu: On Mon, Nov 29, 2010 at 10:31 AM, Hannes Magnússon hannes.magnus...@gmail.com wrote: On Mon, Nov 29, 2010 at 00:51, Loon, Reinier van reinier.van.l...@gmail.com wrote: Hello, I am the lead developer on www.projectpier.org. Our software makes heavy use of __autoload. I was missing the ability to autoload functions in PHP. I think the function __autocall would be an asset as well as __include. __autocall would be called when a function is called which does not exist yet, enabling the developer to write code to dynamically load the code. __include would be called when an include is requested, enabling the developer to write code to dynamically load the file. I searched the lists.php.net for 'include' to see if such a function was requested before. I did not find any, so basically I want to write an RFC. Can you tell me what the proper procedure is for writing an RFC? During the namespace discussions, the subject of autoloading functions came up quite often. You should check out the namespace docs first, and if that doesn't have what you want, check the internals@lists.php.net archives. If you then end up writing an RFC, let us know which username you used to register on the wiki and we'll update your karma there. Creating a new page in the RFC namespace will automatically bring up the RFC template. Larry Garfield submitted a patch for supporting autoloading functions: http://www.mail-archive.com/internals@lists.php.net/msg43992.html Tyrael -- Met vriendelijke groet, Reinier van Loon
Re: [PHP-DEV] Supporting Binary Notation for Integers
On 11/29/2010 05:42 PM, Jonah H. Harris wrote: I've posted a replacement of the 5.3 patch with one against trunk. +1 Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: Making T_FUNCTION optional in method declarations
On 11/27/2010 06:40 PM, Johannes Schlüter wrote: Hi, ... 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 +1 for any PHP version. Insisting on keeping T_FUNCTION means advocating PHP to stay the odd anomaly in programming languages to me. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] new foo()-bar()
On 11/26/2010 08:36 PM, Felipe Pena wrote: Hi all, ... Other examples which describes the feature at http://wiki.php.net/rfc/instance-method-call Thoughts? +1 Finally. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Making T_FUNCTION optional in method declarations
Personally, as a user-land developer, I'm against it, so -1.
function keyword is the only sane way to quickly find a function
definition in lots of code. Not always IDE's are able to fully
understand the interconnections in frameworks and point by CTRL +
Click me to the function definition, not to say that in many cases you
just don't have that IDE available right now and right here.
Now it's quite easy to make a search on a folder recursively - just
enter function blah and here you go - one entry with the function
definition. Try that with the function/method name without the
function keyword, good luck with going through tons of entries.
I deal with typing the whole public/private function blabla() { by
defining a auto complete shortcut like prfnc = space = private
function |(){ where | is cursor.
Please keep it KISS way. Language should evolve for sure, but some
things are not just worth sacrificing the verbosity even if it means
cuts typing some of the most common keywords in the language and can
be perfectly done keeping the BC.
P.S. Personally I will prohibit my developers to use the short syntax
without the function keyword.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Nov 29, 2010, at 4:19 AM, Lester Caine wrote: I've not used git or hg much at all, but bzr has always satisfied my needs for DVCS, and has recently gotten much faster and more space efficient than it was in the past. Sorry, but I think bzr is not a good fit. It's numerous changes to the repository format make it impossible to use. It's either slow if you use an old version, or it's incompatible with old clients, let's say on an old debian box. So I think php.net is better of using mercurial or git, but if we put together an RFC for a migration, I'll make sure bzr is covered as well in an evaluation. Personally I would need a very good reason to add yet another DVCS to the mix here! I've not found bzr as easy to link to from hg as git is. In fact I've not actually got it to play at all as yet ... while hg does work into git with only the problems of managing multiple repo's which is still work in progress on both of them. That said, bzr does seem to handle the multiple repo's in a more user friendly manor? It is just a pity that there is NOT a single target solution for DVCS as everybody is currently scurrying off to their own corners :( The barriers have already been drawn rather then there being concensus on some sort of standard. I think it's high time I tossed in my 1.682¥(JPY) (according to current exchange rates)... I've been out of the PHP dev community for some months now, so anything I say has to be taken with a grain of salt; I simply don't have the time right now to catch up in any detail on the current state of affairs. That in mind, I was already disgusted with SVN by the time the move to it was finished. At the risk of drawing a bit of fire, I have to say I agree with Linus Torvalds' attitude about it, when he said (search Linus Torvalds subversion on Google for the reference) that it was pointless and that CVS couldn't be done right. SVN ditched things CVS had that should've been kept. Sub-repo management (modules) and module merging/aliasing are the two I fought most with during the migration; externals were a BAD patch on the problem! SVN was trying to do CVS right, but that simply doesn't hold together in the modern software development world. Centralized servers by themselves are an old model. Simple, but old. That's why DVCSs exist in the first place! So yes, I think PHP needs to move past Subversion, which is being constantly held back by a model that's just too limited. The branching/merging nightmare seals the coffin, as far as I'm concerned. Which DVCS do I think is best? Git is the massive favorite out there at the moment, according to my Googling. I myself have never been able to fully get my head around it; someone said earlier in the thread that it's a swiss army knife with a boom button, a sentiment I tend to agree with. Still, someone else also correctly said that the huge majority of devs in PHP right now do use it, and that can't be ignored. It is my observation that the Windows issues have been largely solved in more recent times. GitHub itself (while I would prefer something we host ourselves), is pretty easy to use. I don't know much about Mercurial, having never used it, so I can't comment much on it. The fact that it continues to be prevalent at all versus Git says something for it, but it falls down against the ubiquity argument, as a quick glance suggests to me that the learning curve would actually be a bit worse than Git's. Its Web interface makes me cringe. Bazaar is -my- current favorite, as its commands tend to translate almost directly from SVN's and while a minority, it has a passionate following (largely thanks to Ubuntu and MySQL, I think). But it being my personal favorite doesn't mean much. I also find Launchpad a bit incomprehensible, and Bazaar being written in Python feels a little odd to me. Don't we rely enough already on competing languages? :) (Mercurial also suffers from this.) I am not going to attempt any kind of conclusion based on technical merits (branching/merging ability, sub-repo support, etc.), as I don't know what the status of these features is, and even if I did, I no longer have enough knowledge of PHP's current state to apply the knowledge. So, I have to base my thought on what the most people are going to have the least trouble working with, and that's Git, hands down. There are more than enough people around the community with the full knowledge necessary to undertake the migration with minimum fuss; it's been pointed out that the kind of massive manual balancing I had to do for CVS-SVN would be completely absent. I just wish I didn't have to also admit that Trac is a really great project management system. Unless things have changed drastically since I was last active, PHP still needs one. ^^; -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Making T_FUNCTION optional in method declarations
On Nov 30, 2010, at 4:24 AM, Arvids Godjuks wrote:
Personally, as a user-land developer, I'm against it, so -1.
function keyword is the only sane way to quickly find a function
definition in lots of code. Not always IDE's are able to fully
understand the interconnections in frameworks and point by CTRL +
Click me to the function definition, not to say that in many cases you
just don't have that IDE available right now and right here.
Now it's quite easy to make a search on a folder recursively - just
enter function blah and here you go - one entry with the function
definition. Try that with the function/method name without the
function keyword, good luck with going through tons of entries.
I deal with typing the whole public/private function blabla() { by
defining a auto complete shortcut like prfnc = space = private
function |(){ where | is cursor.
Please keep it KISS way. Language should evolve for sure, but some
things are not just worth sacrificing the verbosity even if it means
cuts typing some of the most common keywords in the language and can
be perfectly done keeping the BC.
P.S. Personally I will prohibit my developers to use the short syntax
without the function keyword.
Agreed. -1 here also.
-- Gwynne
--
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/27 Johannes Schlüter johan...@schlueters.de
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Considering variables are prefixed and constants don't have visibility
modifiers, functions in classes would still be easily recognizable.
Syntax analyzing IDEs generally don't rely on single keywords and will
be able to adapt a change like this without too much hassle.
On top of that, seeing that functions in classes are generally
referred to as methods, I believe removing the requirement would
improve consistency.
+1 from me.
Kind regards,
Peter Beverloo
--
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/27 Johannes Schlüter johan...@schlueters.de:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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?
Cheers,
--
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] git anyone?
On Tue, Nov 30, 2010 at 10:49 AM, Gwynne Raskind gwy...@darkrainfall.orgwrote: On Nov 29, 2010, at 4:19 AM, Lester Caine wrote: I've not used git or hg much at all, but bzr has always satisfied my needs for DVCS, and has recently gotten much faster and more space efficient than it was in the past. Sorry, but I think bzr is not a good fit. It's numerous changes to the repository format make it impossible to use. It's either slow if you use an old version, or it's incompatible with old clients, let's say on an old debian box. So I think php.net is better of using mercurial or git, but if we put together an RFC for a migration, I'll make sure bzr is covered as well in an evaluation. Personally I would need a very good reason to add yet another DVCS to the mix here! I've not found bzr as easy to link to from hg as git is. In fact I've not actually got it to play at all as yet ... while hg does work into git with only the problems of managing multiple repo's which is still work in progress on both of them. That said, bzr does seem to handle the multiple repo's in a more user friendly manor? It is just a pity that there is NOT a single target solution for DVCS as everybody is currently scurrying off to their own corners :( The barriers have already been drawn rather then there being concensus on some sort of standard. I think it's high time I tossed in my 1.682¥(JPY) (according to current exchange rates)... I've been out of the PHP dev community for some months now, so anything I say has to be taken with a grain of salt; I simply don't have the time right now to catch up in any detail on the current state of affairs. That in mind, I was already disgusted with SVN by the time the move to it was finished. At the risk of drawing a bit of fire, I have to say I agree with Linus Torvalds' attitude about it, when he said (search Linus Torvalds subversion on Google for the reference) that it was pointless and that CVS couldn't be done right. SVN ditched things CVS had that should've been kept. Sub-repo management (modules) and module merging/aliasing are the two I fought most with during the migration; externals were a BAD patch on the problem! SVN was trying to do CVS right, but that simply doesn't hold together in the modern software development world. Centralized servers by themselves are an old model. Simple, but old. That's why DVCSs exist in the first place! So yes, I think PHP needs to move past Subversion, which is being constantly held back by a model that's just too limited. The branching/merging nightmare seals the coffin, as far as I'm concerned. Which DVCS do I think is best? Git is the massive favorite out there at the moment, according to my Googling. I myself have never been able to fully get my head around it; someone said earlier in the thread that it's a swiss army knife with a boom button, a sentiment I tend to agree with. Still, someone else also correctly said that the huge majority of devs in PHP right now do use it, and that can't be ignored. It is my observation that the Windows issues have been largely solved in more recent times. GitHub itself (while I would prefer something we host ourselves), is pretty easy to use. I don't know much about Mercurial, having never used it, so I can't comment much on it. The fact that it continues to be prevalent at all versus Git says something for it, but it falls down against the ubiquity argument, as a quick glance suggests to me that the learning curve would actually be a bit worse than Git's. Its Web interface makes me cringe. Bazaar is -my- current favorite, as its commands tend to translate almost directly from SVN's and while a minority, it has a passionate following (largely thanks to Ubuntu and MySQL, I think). But it being my personal favorite doesn't mean much. I also find Launchpad a bit incomprehensible, and Bazaar being written in Python feels a little odd to me. Don't we rely enough already on competing languages? :) (Mercurial also suffers from this.) I am not going to attempt any kind of conclusion based on technical merits (branching/merging ability, sub-repo support, etc.), as I don't know what the status of these features is, and even if I did, I no longer have enough knowledge of PHP's current state to apply the knowledge. So, I have to base my thought on what the most people are going to have the least trouble working with, and that's Git, hands down. There are more than enough people around the community with the full knowledge necessary to undertake the migration with minimum fuss; it's been pointed out that the kind of massive manual balancing I had to do for CVS-SVN would be completely absent. I just wish I didn't have to also admit that Trac is a really great project management system. Unless things have changed drastically since I was last active, PHP still needs one. ^^; -- Gwynne -- PHP Internals - PHP Runtime
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
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 ;-)
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Nov 30, 2010, at 5:10 AM, Ferenc Kovacs wrote: I just wish I didn't have to also admit that Trac is a really great project management system. Unless things have changed drastically since I was last active, PHP still needs one. ^^; just a little comment on the last statement: do you know about mtrack? it is a trac clone written in php by Wez *Googles.* *Reads.* Well... dang. Go Wez!! I like it :-). Thanks for the pointer! I'll have to look into that in more detail soon, it could prove very useful. And it looks a good bit better than Trac too ;-). -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] C++ comments in Zend
Zend/zend_compile.h:508:1: warning: C++ style comments are not allowed in ISO C90 Zend/zend_compile.h:508:1: warning: (this will be reported only once per input file) Lines 508 and 509 Someone with Zend karma, please, fix this. Compiled in trunk. Thanks, Andrey -- 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,
I'd really like this feature to be part of PHP.
I don't particularly like the use of what looks like a closure for the
set/get.
While it looks like a closure, it may not necessarily be one. What I have
presented in my RFC is a syntax, but I make little assumption about how it
would be implemented, as that would be out stepping my expertise.
In C#, when a property gets compiled it is actually turned into two normal
class methods in a special namespace. Looking at a compiled C# library
with reflector will reveal this underlying implementation. So when a call
to a property is compiled in C#, it is simple replaced with a call to a
method. The properties themselves are nothing more than syntactic sugar.
Since PHP is interpreted instead of compiled, this may not be an ideal
solution, but I couldn't guess as to what would be a better method.
Preferably something that re-uses the existing class method
interpretation.
I used to code in Delphi and I always like the way in which their
properties were defined.
Essentially, the setter and getter are normal methods which are cherry
picked for a property [1].
?php
class TimePeriod
{
protected $seconds;
public property Hours read getHours write setHours;
protected function getHours()
{
return $this-seconds / 3600;
}
protected function setHours()
{
$this-seconds = $value * 3600;
}
// This property is read-only
public property Minutes read getMinutes;
protected function getMinutes()
{
return $this-seconds / 60;
}
public property Milliseconds read getMilliseconds write
setMilliseconds;
public function getMilliseconds()
{
// This method is public
return $this-seconds * 60;
}
protected function setMilliseconds()
{
// This method is protected
$this-seconds = $value * 3600;
}
}
For me, the advantage here is that I can independently the methods
from the property. If I want to force a subclass to implement a
setter/getter, then I can abstract the function in the base class.
Sure, some may say that I should be using an interface. I disagree as
I probably don't want the methods to be public. Protected or even
private and/or final.
In the syntax I provided in my RFC, it is certainly possible to define a
property with only a get or only a set method (these are implicit
read-only and write-only properties). Furthermore, it is also possible to
set the visibility of the get and set methods individually, as well as
making either one final, static or (and I forgot to mention this in the
RFC) abstract. But the advantage of my syntax, is not only can these
things be set individually, but they can also be set just once for the
pair, by specifying them on the property itself. This makes for cleaner
and more readable code.
My syntax also gives several other advantages over the delphi syntax. It
is more logical, as it makes the property look more like a class variable
than a class method. This makes sense because you call it like a
variable. Additionally, because the get/set methods need to be contained
within the body of the property definition, you immediately know if a
property has both a get and a set method at a quick glance - you do not
have to hunt through the class to see if there is another definition
somewhere else.
The classic example is one of shapes. Every shape has a public $area
property, but the value would be provided by an abstract protected
TShape::getArea(); method. I can also finalise them, so, for example,
a triangle shape could have a final protected getArea() method and all
sub classes of triangles (scalene, isosceles, equilateral) would not
implement their own getArea() method.
This is possible with the syntax I provided. I would suggest reading more
about the C# syntax, which my suggested syntax is based off of, as it will
explain all of your questions.
http://msdn.microsoft.com/en-us/library/x9fsa0sw%28VS.80%29.aspx
- Dennis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: C++ comments in Zend
On 2010-11-30, Andrey Hristov p...@hristov.com wrote: Zend/zend_compile.h:508:1: warning: C++ style comments are not allowed in ISO C90 Zend/zend_compile.h:508:1: warning: (this will be reported only once per input file) Lines 508 and 509 Someone with Zend karma, please, fix this. Compiled in trunk. Thanks. Fixed -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting Binary Notation for Integers
-1 I don't think this is necessary. On Wed, Nov 10, 2010 at 4:31 PM, Jonah H. Harris jonah.har...@gmail.com wrote: Hey all, I was recently working on some code which made use of bit arrays and I came across feature request 50648: Format for binary numbers. While it's just more syntactic sugar (0b1011010 vs 2010/0x7da/03732), it doesn't seem like too bad of an idea and it is also supported by a few other languages. If there's any interest, I'll clean up the patch and resubmit. Thoughts? -- Jonah H. Harris Blog: http://www.oracle-internals.com/ -- 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,
Hi!
Nice RFC, just an idea for an alternative syntax (added to the RFC
as
#2):
property Hours {
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; } // The variable $value
holds
the incoming value to be set
}
class TimePeriod
{
private $seconds;
public [Hours] $hours1;
public {use Hours;} $hours2;
}
If you change property to class or trait and get to __get
you need almost no new syntax :)
Right, it looks the same but the subtle difference is 'property Hours'
wouldn't be registered as a class. It's just container code for get(),
set()
methods that would get 'compiled' into opcodes in the class TimePeriod
(the
property exists vs. searching for it in runtime). So you can think of it
as
a special 'trait' that only applies to properties.
The idea behind this syntax is you can move the 'property' definition out
of
the class so that you can test and re-use it somewhere else (like traits).
That might not be problem if you can define properties in traits (needs to
be explained in the RFC):
trait TimeUnits {
public property Seconds
{
get { return $this-seconds; }
set { $this-seconds = $value; }// The variable $value holds the
incoming value to be set
}
public property Minutes
{
get { return $this-seconds / 60; }
set { $this-seconds = $value * 60; }
}
public property Hours
{
get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; }// The variable $value
holds
the incoming value to be set
}
}
class MyTime {
uses TimeUnits;
protected $_seconds;
}
I do not think that properties should make use of a trait-like syntax, as
that is not what a property is about. A property is basically a layer of
syntactic sugar over a pair of methods. The majority of the time when
writing properties, you will not want to re-use them, so I have a hard
time seeing many parallels to traits.
However, it does make sense to be able to define a property as part of a
trait, as again, it is basically just a pair of methods. When I get some
time, I will try to add a syntax for traits to the RFC.
- 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: On 30 Nov 2010, at 14:42, presid...@basnetworks.net wrote: However, it does make sense to be able to define a property as part of a trait, as again, it is basically just a pair of methods. When I get some time, I will try to add a syntax for traits to the RFC. The only thing really necessary for that would be a specification on how to name/to refer to the getter/setter to be able to handle the conflicts. The rest should work out of the box. As far as I can see from the proposal. Best regards Stefna - Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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
Hi! I do not think that properties should make use of a trait-like syntax, as that is not what a property is about. A property is basically a layer of syntactic sugar over a pair of methods. The majority of the time when writing properties, you will not want to re-use them, so I have a hard time seeing many parallels to traits. A side note: in PHP, property actually has four methods, not two - get/set/unset/isset. -- 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
2010/11/29 Ángel González keis...@gmail.com: Richard Quadling wrote: As for reading $seconds directly ... Well. If you think of the element that follows read as $this-, then if the parser can handle both ... read $seconds read getSeconds then yes for both. If not, then I'd guess that the getSeconds version should be the one we use as the value may not actually exist without some processing. Richard. If it begins with $, it's a variable name, so map to that class member variable. If it is instead a plain T_STRING, take that as a member call. I'm not sure to be understanding the issue you're mentioning. If the proposal incorporated support for getting the value from a local-scoped variable (I assume the variable has to be part of the current class or one of its parents?) as well as calling the getter, then that really does seem to allow everyone everything they need. -- 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
Hello Stas, I do not think that properties should make use of a trait-like syntax, as that is not what a property is about. A property is basically a layer of syntactic sugar over a pair of methods. The majority of the time when writing properties, you will not want to re-use them, so I have a hard time seeing many parallels to traits. A side note: in PHP, property actually has four methods, not two - get/set/unset/isset. That is true for PHP variables. isset is basically saying does this variable exist, and unset is saying to get rid of it. Because properties (as defined in my RFC) are not a variable, but rather a set of methods, I do not think there would be any way to unset them. Like a method, once they are defined, you cannot get rid of them. Therefore overloading isset and unset would not make any sense here. - 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
On Tue, 2010-11-30 at 09:15 -0500, 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. Because properties (as defined in my RFC) are not a variable, but rather a set of methods, I do not think there would be any way to unset them. Like a method, once they are defined, you cannot get rid of them. Therefore overloading isset and unset would not make any sense here. This is different from the PHP Language then. You can isset() and unset() native properties. And use __isset() and __unset() magic methods. A new feature should be consistent with the language definition. 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
Hi! 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)? -- 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 30 November 2010 12:48, presid...@basnetworks.net wrote:
Hi Richard,
I'd really like this feature to be part of PHP.
I don't particularly like the use of what looks like a closure for the
set/get.
While it looks like a closure, it may not necessarily be one. What I have
presented in my RFC is a syntax, but I make little assumption about how it
would be implemented, as that would be out stepping my expertise.
In C#, when a property gets compiled it is actually turned into two normal
class methods in a special namespace. Looking at a compiled C# library
with reflector will reveal this underlying implementation. So when a call
to a property is compiled in C#, it is simple replaced with a call to a
method. The properties themselves are nothing more than syntactic sugar.
Since PHP is interpreted instead of compiled, this may not be an ideal
solution, but I couldn't guess as to what would be a better method.
Preferably something that re-uses the existing class method
interpretation.
I used to code in Delphi and I always like the way in which their
properties were defined.
Essentially, the setter and getter are normal methods which are cherry
picked for a property [1].
?php
class TimePeriod
{
protected $seconds;
public property Hours read getHours write setHours;
protected function getHours()
{
return $this-seconds / 3600;
}
protected function setHours()
{
$this-seconds = $value * 3600;
}
// This property is read-only
public property Minutes read getMinutes;
protected function getMinutes()
{
return $this-seconds / 60;
}
public property Milliseconds read getMilliseconds write
setMilliseconds;
public function getMilliseconds()
{
// This method is public
return $this-seconds * 60;
}
protected function setMilliseconds()
{
// This method is protected
$this-seconds = $value * 3600;
}
}
For me, the advantage here is that I can independently the methods
from the property. If I want to force a subclass to implement a
setter/getter, then I can abstract the function in the base class.
Sure, some may say that I should be using an interface. I disagree as
I probably don't want the methods to be public. Protected or even
private and/or final.
In the syntax I provided in my RFC, it is certainly possible to define a
property with only a get or only a set method (these are implicit
read-only and write-only properties). Furthermore, it is also possible to
set the visibility of the get and set methods individually, as well as
making either one final, static or (and I forgot to mention this in the
RFC) abstract. But the advantage of my syntax, is not only can these
things be set individually, but they can also be set just once for the
pair, by specifying them on the property itself. This makes for cleaner
and more readable code.
My syntax also gives several other advantages over the delphi syntax. It
is more logical, as it makes the property look more like a class variable
than a class method. This makes sense because you call it like a
variable. Additionally, because the get/set methods need to be contained
within the body of the property definition, you immediately know if a
property has both a get and a set method at a quick glance - you do not
have to hunt through the class to see if there is another definition
somewhere else.
The classic example is one of shapes. Every shape has a public $area
property, but the value would be provided by an abstract protected
TShape::getArea(); method. I can also finalise them, so, for example,
a triangle shape could have a final protected getArea() method and all
sub classes of triangles (scalene, isosceles, equilateral) would not
implement their own getArea() method.
This is possible with the syntax I provided. I would suggest reading more
about the C# syntax, which my suggested syntax is based off of, as it will
explain all of your questions.
http://msdn.microsoft.com/en-us/library/x9fsa0sw%28VS.80%29.aspx
- Dennis
Thanks for your reply.
Fundamentally, a big +1 from my little voice on having setters/getters in PHP.
The issue of documentation is probably that the documentation tools
would have to adapt. As things stand PHPDoc doesn't support
namespaces, so setters/getters would just be added to the WIBNI list.
With regard to the value supplied to the set method, would it make
more sense for PHP to be ...
set($value) { $this-seconds = $value * 3600; }
or
set { $this-seconds = __SETVALUE__ * 3600; }
Having $value without a clear indication of where it comes from
doesn't read quite right.
$value is way to generic to be magically created. __SETVALUE__ (or
__SOMETHINGELSE__) is clear in this regard.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
Re: [PHP-DEV] Supporting Binary Notation for Integers
On Tue, Nov 30, 2010 at 8:22 AM, Ilia Alshanetsky i...@prohost.org wrote: -1 I don't think this is necessary. It's certainly not necessary; it's a nice to have. Given the small amount of code required to implement the functionality, I believe it's worthwhile to add the notation as an option for developers to use. -- Jonah H. Harris Blog: http://www.oracle-internals.com/
Re: [PHP-DEV] Supporting Binary Notation for Integers
+1, next major version. On Mon, Nov 29, 2010 at 5:42 PM, Jonah H. Harris jonah.har...@gmail.com wrote: -- 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] git anyone?
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
Re: [PHP-DEV] git anyone?
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
[PHP-DEV] ts_free_thread() frees only temporary in multiple parallel threads
OS:Windows (XP and 7 tested)
PHP: 5.2.9 and 5.3.3
I created my own php sapi 1 year ago and it was only single threaded.
Now I tried to make it multi-threaded by using TSRM.
I got 1 thread starting up and shutting down the TSRM and my module and
many other threads executing requests. You can take a look at this
abstract example here:
DWORD WINAPI test_thread(void*)
{
TSRMLS_FETCH() // a lot of memory is allocated here
// execute the request (just core functions written here)
php_request_startup(TSRMLS_C);
php_execute_script(fh, TSRMLS_C);
php_request_shutdown(TSRMLS_C);
ts_free_thread(); // I tried to free the memory allocated through
TSRMLS_FETCH() here
}
int main()
{
tsrm_startup(25, 1, 0, NULL);
sapi_startup(my_php_sapi);
php_module_startup(my_php_sapi, NULL, 0);
sapi_activate(TSRMLS_C);
// start 25 threads running test_thread() here using CreateThread()
// call module/sapi shutdown functions
tsrm_shutdown(); // all memory gets freed here
}
The request threads work fine but I noticed that all the copies allocated
through TSRMLS_FETCH() last in the memory until tsrm_shutdown() gets
executed. So I browsed the web and found that ts_free_thread() should
solve it. But now here's the problem:
When I'm executing only 1 request thread at a time, everything works fine
and ts_free_thread() frees all resources. But when I run multiple threads
at the same time the memory gets up and down until all threads finished.
But after all threads exited the memory grows up enormous.
This is what happens:
- start 25 threads-- memory: ~25.000 k
- threads finish one by one -- memory: ~25.000 k -- ~4.000 k
- all threads finished-- memory: ~50.000 k
I was using php 5.2.9 and now tried the same with the latest stable 5.3.3
release but the problem still resists.
I couldn't really locate the problem yet.
--
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
Richard Quadling wrote: (I assume the variable has to be part of the current class or one of its parents?) Yes. I don't think it makes sense to have a class property actually read a global. If a project really need it (eg. some migration from procedural style to classes), then use the verbose syntax. -- 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
I still want to keep the performance implications in mind, as this sounds like something that we'd want to use a lot but could also cost a lot more than it seems at first glance if we're not careful. By making properties in memory a little bigger one might write the accessors in the same table as the actual properties one might possibly reduce the CPU requirement abit. While one has to touch most places dealing with properties internally (while that's probably needed anyways). But well, unless there is an implementation all performance ideas are guesses ... educated guesses at best. Just to chime in on the subject of performance, here is how C# handles properties: When compiling, C# simply creates a normal class method for both the get and set method in a property. So basically, the property ceases to exist, and is replaced with two plain methods. These methods are either in their own namespace (or more likely) use a name that is not valid or possible in C# itself. After that, all calls to the property are replaced with calls to the new methods. Because of this, properties have no greater overhead than methods do, which is exactly what we want, since properties are meant to replace getter and setter methods. How much this informs performance in PHP, I do not know. - 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 Benjamin,
I have been working with Objective-c lately, and it has a very flexible
and short way to deal with properties, which could look like this in PHP :
?php
class TimePeriod {
protected $seconds;
protected $minutes;
protected $hours;
@synthesize (readwrite) $hours, $minutes;
@synthesize (readonly) $seconds;
}
NB : I intentionally skipped the @property declaration wich I believe is a
specific need for objc (used to allow dot syntax usage).
In objc, this notation allows to :
- use dot syntax for accessing properties (using their getters/setters
only, all properties are protected in objc)
- write your own getters/setters (only the missing ones are generated)
In Php, the pros of this syntax would be :
- very concise
- no interference with existing code (except certain conditions)
- allows to override generated getters and setters with custom code
- may work with the existing code base
The cons :
- new syntax to learn (even if it is quite simple)
- need to use pre-determined setters and getters names to keep simplicity,
which could potentially lead to BC break in some (hopefully rare) cases.
What do you think about it ?
The issue I have with this syntax is it does not look similar to any other
syntax in PHP (that I know of). It looks out of place. Additionally, I
believe the readonly and writeonly keywords are slated to have other
meanings (as noted in my RFC), and this would cause confusion. Also, if a
property is defined readonly, when we inherit the class, how do we now
define the write method? I don't see any logical or coherent way with
this syntax.
Lastly, your syntax misses the point of properties. The point is not to
put an alias on an existing variable, or even to read and write to
different variables. The real power is that the get and set are methods!
For example, in the get method, I could make a soap call to another
server, load in a result document and get my value from there. In a set
method, I could make a database call and store the value. These are
extreme scenarios, but they show the power 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
This is a very well-written and well-thought through RFC, Dennis. Nicely
done.
Thank you!
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.
However, I do see a potential use here if properties are treated
conceptually as an entirely new concept and not as an indirection layer for
class properties. That would make them more akin to a class that has both
methods and also implements ArrayAccess for properties of the conceptual
object, that may not have anything to do with internal class members.
Viewed from that angle, I would have the following comments:
- I strongly prefer the first syntax over the second. The property
keyword
improves readability, and the closing semi-colon is going to be
forgotten on a
daily basis. I still forget sometimes when to use it and when not to when
writing Javascript. :-) I cannot speak to the engine complexity
involved but
from a PHP-autor point of view I believe the first syntax is much easier to
use.
Right, the property keyword ties together with the function keyword, and
the semi-colon provides no real purpose to the author. I have however
been told that the semi-colon is important from an internal perspective,
and would ease the implementation.
- The use of identical syntax for class members and properties could create
confusion as to which is which. One could argue that is the point, but
only
if we view properties as just an indirection layer around the physical
class
members, which as I noted above I believe is a poor architectural design.
There may not be an alternative here, but I mention it for completeness.
Using the same syntax is exactly the point of properties, and is what
gives them their power. From the outside, properties should look and act
no differently than a simple variable class member. This is encapsulation
at its greatest, because it hides the implementation! It is not important
for a user of a class to know which is a property and which is a variable
underneath. To use a different syntax would be to expose that.
Another cool side effect of variables and properties sharing the same
syntax, is that a variable can be replaced with a property that has the
same name, at any time (and vice-versa) and all code that calls that
member will continue to work. This is eternally useful when writing class
libraries, where you want to do something more advanced with a class
variable internally, but do not want to break the API.
- The layering of accessibility keywords I find intriguing, in a mostly
good
way. That can offer a great deal of flexibility to control who can do what
when. However, I am concerned about the confusion possible in the
following:
public property Hours {
get { return $this-seconds / 3600; }
protected set { $this-seconds = $value * 3600; }
}
The set method is then scoped with two different visibility directives:
public
and protected. Which applies? Since both are optional (presumably) I
can see
a potential here for confusion, especially if you also start mentioning
keywords like final. This should be made more definitive if possible.
The inner keywords always take precedence over the outer ones. So in this
case by making the property public, and the set protected, it means
the get is public and the set is protected.
This would mean the same thing:
property Hours {
public get { return $this-seconds / 3600; }
protected set { $this-seconds = $value * 3600; }
}
However, many people prefer to write it the way you quoted above, because
they don't like to leave the outer property without a visibility keyword.
Perhaps a better choice (which is also equivalent) would have been this:
protected property Hours {
public get { return $this-seconds / 3600; }
set { $this-seconds = $value * 3600; }
}
Each one of these scenarios works as described in C#, and rarely causes
confusion. The rule of thumb, is that if a get/set has no visibility
keyword, it inherits the one from the outer property. I think that is
fairly simple.
- If interfaces can declare properties (niiice), Traits should be able to
provide them. That provides full parallelism with methods, which I believe
developers will expect.
I agree, properties
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
...
/**
*
*/
public function set name(string $name) {
$this-name = htmlentities($name);
$this-name = strip_tags($this-name);
}
/**
*
*/
public function get name($name) {
return $this-name;
}
Greetings,
Christian
For whatever it's worth, I think that this syntax fits much better
into PHP than do either of the those in the RFC.
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
--
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 -- 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 11/30/10 6:15 PM, presid...@basnetworks.net wrote: 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. They do for __*() magic methods and for ArrayAccess (albeit named differently), so there should be some sort of meaningful definition here. Otherwise they are only half a drop-in/break-no-API replacement for a class member. --Larry Garfield -- 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
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. 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. 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 -- 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)? As I replied elsewhere: 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. __isset is a whole different matter, without it we would have to assume that every possible member name in a class either exists or does not exist. This is because __isset, __get, __set and __unset 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. - 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
On 11/30/10 5:55 PM, presid...@basnetworks.net wrote:
This is a very well-written and well-thought through RFC, Dennis. Nicely
done.
Thank you!
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.)
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.
I'm not going to say pick one! because both are valid use cases with
significant benefit, but it is a point of potential confusion in both
the discussion and eventual documentation.
Right, the property keyword ties together with the function keyword, and
the semi-colon provides no real purpose to the author. I have however
been told that the semi-colon is important from an internal perspective,
and would ease the implementation.
Another reason that the function keyword should remain mandatory, IMO.
:-) I cannot speak to the implementation details, but I do know that
the semi-colon would horribly confuse a lot of people.
In C#, get and set methods of a property are compiled down to methods, and
calls to a property are changed to calls to those methods. Therefore
their performance in C# is exactly that of a method call. This is ideal,
since properties are meant to be a replacement for the standard
getXYZ/setXYZ design pattern.
I cannot speak to the implementation potential in PHP as I have never
looked at the compiler's code.
- 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.)
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. :-)
That's all I got for now. Once again, nice RFP but still needs some
thinking.
Of course, that is why I am harnessing your collective brains!
BRAAAINS!
--Larry Garfield
--
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
Thanks for your reply.
Fundamentally, a big +1 from my little voice on having setters/getters in
PHP.
The issue of documentation is probably that the documentation tools
would have to adapt. As things stand PHPDoc doesn't support
namespaces, so setters/getters would just be added to the WIBNI list.
Here is a reply I wrote to Christan Kaps on the same subject:
Christan Wrote:
I like the idea of the property get/set syntax, but in my opinion it
doesn't figure with PHP's syntax, because it breaks the readability. The
problem for me is the nesting of the inner set and get. How do you
document these syntax.
/**
*
*/
public $name {
/**
*
*/
get {
return $this-name;
}
/**
*
*/
set {
$this-name = htmlentities($value);
$this-name = strip_tags($this-name);
}
};
Typically you only document the property as a whole, and not the
individual get and set method. Since they are a pair, there should be no
reason to document them separately. If the get method is doing something
totally different from the set, then they should not be paired, as that is
confusing.
In C# you would typically see documentation like this:
Only a get method:
/// summaryGets the duration of the Timespan in seconds./summary
public int Seconds { get; }
Only a set method:
/// summarySets the duration of the Timespan in seconds./summary
public int Seconds { set; }
Both a get and set method:
/// summaryGets/sets the duration of the Timespan in seconds./summary
public int Seconds { get; set; }
With regard to the value supplied to the set method, would it make
more sense for PHP to be ...
set($value) { $this-seconds = $value * 3600; }
or
set { $this-seconds = __SETVALUE__ * 3600; }
Having $value without a clear indication of where it comes from
doesn't read quite right.
$value is way to generic to be magically created. __SETVALUE__ (or
__SOMETHINGELSE__) is clear in this regard.
That is a good point. In C# it is simple the variable value, which is
where I got $value from. Rather magicy, yes. A constant could work, and
would be more in line with PHP's magic constants. Just a quick question
though, can a constant store all of the same data variable can? What
about a reference?
Also, sometimes users in C# like to modify the contents of the value
variable before using it for something else. If it were a constant this
would not be possible, you would have to define a new variable, then copy
the value from the constant, which seems unnecessarily cumbersome.
- 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
On 11/30/10 6:29 PM, 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.
Because properties (as defined in my RFC) are not a variable, but rather
a
set of methods, I do not think there would be any way to unset them.
Like a method, once they are defined, you cannot get rid of them.
Therefore overloading isset and unset would not make any sense here.
This is different from the PHP Language then. You can isset() and
unset() native properties. And use __isset() and __unset() magic
methods.
A new feature should be consistent with the language definition.
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.
__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.
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.
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.
Details of my adventures in __get() insanity here, including performance
considerations:
http://www.garfieldtech.com/blog/magical-php-call
How would properties deal with those scenarios? (The answer may well be
it doesn't, screw off, that's way too esoteric, as it is for __get(),
but we should at least consider if it's possible to handle those
gracefully.)
--Larry Garfield
--
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
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?
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
- Davey
On Nov 30, 2010, at 7:31 PM, 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)?
As I replied elsewhere:
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.
__isset is a whole different matter, without it we would have to assume
that every possible member name in a class either exists or does not
exist. This is because __isset, __get, __set and __unset 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.
- Dennis
--
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
