On 5 December 2010 16:47, presid...@basnetworks.net wrote:
If I have an object called PiggyBank, with the property dollars set to
5, dimes set to 4 and nickles set to 1, then I get the contents of the
property Total, I can predict it will give me the value 5.45. That is
what properties are
On 5 December 2010 16:47, presid...@basnetworks.net wrote:
If I have an object called PiggyBank, with the property dollars set
to
5, dimes set to 4 and nickles set to 1, then I get the contents of
the
property Total, I can predict it will give me the value 5.45. Â That
is
what properties
The original purpose being, specifically, smarter class members,
correct? (The internal syntax to define them we can bikeshed later;
determining the external syntax and semantics has to come first.)
Well when saying original purpose I was referring to exactly this:
The basic Idea of a
In a multi-user system, any of these values could be different from
one moment to the next.
class Account{
public property $AvailableBalance{
get{
return $this-CreditLimit - ($this-AccountBalance - $this-OnOrder);
}
}
}
This hides the mechanics away and tells any user that the
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 ==
How does one get a reference to a property, if a property is just a
collection
of methods with fancy behavior? That makes properties a first class
entity,
which is an entirely different bit of brain bending.
Its the same concept as having a reference to a function, where you can
invoke
Hi Chad,
Having thought a bit about this, there are a couple of initial
problems I see, and, more importantly, I'm not convinced that the
stated problem (encapsulation) requires the addition of a new language
construct (i.e. a property as distinct from a class member). In
fact, I think it
Hi Dennis
2010/12/5 presid...@basnetworks.net:
Interesting. So you are saying that once a word is a keyword in PHP, it
cannot be used as a name, anywhere? So for example, you are saying I
cannot create a variable called $function? If that is the case, that is
extremely odd. I would
On Sunday, December 05, 2010 11:07:49 am presid...@basnetworks.net wrote:
The original purpose being, specifically, smarter class members,
correct? (The internal syntax to define them we can bikeshed later;
determining the external syntax and semantics has to come first.)
Well when
Interesting. So you are saying that once a word is a keyword in PHP, it
cannot be used as a name, anywhere? So for example, you are saying I
cannot create a variable called $function? If that is the case, that is
extremely odd. I would expect that get/set could be keywords when used
in
Hi Dennis
2010/12/6 presid...@basnetworks.net:
Could this easily be used (and would it make sense to use them) in this
situation? I think the best solution is for get/set to be keywords, but
only in the context of a property definition. Will this accomplish the
task?
I'm sure it can be
On Thu Dec 2 02:11 AM, Larry Garfield wrote:
See, here's the fundamental problem we're running into. There's three
different definitions of what a property is that we keep bouncing
between, each of which will dictate both syntax and semantics:
1) Properties are a smart masking layer
Why change the expected behavior of isset? If a property has not been
set
then isset must return false, and that includes $foo-name = NULL.
Regards.
Say the property is write-only. How can isset() operate on that? If
the property is read-only, how can you unset() it?
If the property is
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
Hello Stas,
In PHP, of course, class properties are dynamic, so you can add and
delete them at will. It is a standard feature of dynamic languages. For
a person coming from strict compiled language like C# it might be
unusual, but that's how dynamic languages work.
No not unusual at all.
Hi Stefan,
Unfortunately I find that to be one of the major downfalls of PHP. It
sometimes disregards defacto standards that are set across the entire
industry, which causes a lot of frustration for new programmers.
Sometimes the functionality PHP adds by going its own way is worth it,
but
Hi Lester,
Its a defacto standard. Of course there is nothing stopping PHP from
implementing properties that way, but by going against the standard set
by
the rest of the industry, it is very confusing for programmers coming
from
other languages to learn PHP. A good example is how ==
Hi Derick,
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
-1
Derick
Care to elaborate? I'm not sure much consideration will be taken of your
opinion unless you put some words behind it. I am curious to know why you
did not like the RFC?
Regards,
- Dennis
--
PHP
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
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
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,
Hi Larry,
Hmm, I would have programmed it liked this:
if ($account-beneficiary != null) {
print $account-beneficiary-name;
}
To me, if a property is not set, it means it does not exist and will
not
be a valid property at any point in the object's lifetime. Null means
that it is a
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.
On 2 December 2010 13:51, presid...@basnetworks.net wrote:
2010/12/1 Richard Quadling rquadl...@gmail.com
On 1 December 2010 09:22, Stas Malyshev smalys...@sugarcrm.com wrote:
...
Why change the expected behavior of isset? If a property has not been set
then isset must return false, and
On 12/2/10 8:42 AM, presid...@basnetworks.net wrote:
How does one get a reference to a property, if a property is just a
collection
of methods with fancy behavior? That makes properties a first class
entity,
which is an entirely different bit of brain bending.
Its the same concept as
Having thought a bit about this, there are a couple of initial
problems I see, and, more importantly, I'm not convinced that the
stated problem (encapsulation) requires the addition of a new language
construct (i.e. a property as distinct from a class member). In
fact, I think it is better
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
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
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
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.
--
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
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
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
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
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
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
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/
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
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
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
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
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
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()
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
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
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
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
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:
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
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
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.
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
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:
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
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
{
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
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
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
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
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
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
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
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
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
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
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
...
/**
*
*/
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
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
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
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
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
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
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
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
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
On Sun, Nov 28, 2010 at 11:48 PM, Christian Kaps
christian.k...@mohiva.com wrote:
...
/**
*
*/
public function set name(string $name) {
$this-name = htmlentities($name);
$this-name = strip_tags($this-name);
}
/**
*
*/
public function get name($name) {
return $this-name;
On 28 November 2010 23:18, presid...@basnetworks.net wrote:
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
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.
I used to code
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;
Richard Quadling wrote:
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.
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
On 2010-11-29, Richard Quadling rquadl...@gmail.com wrote:
On 28 November 2010 23:18, presid...@basnetworks.net wrote:
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
I'd really like this feature to be part of PHP.
I don't particularly like the
On 2010-11-29, Stas Malyshev smalys...@sugarcrm.com wrote:
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
Hi!
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.
Having them called __get etc. would
On Mon Nov 29 09:27 AM, Stas Malyshev wrote:
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
On 11/29/10 11:51 AM, Jonathan Bond-Caron wrote:
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.
On 11/29/10 8:30 AM, Ángel González wrote:
What about allowing this syntax to attach the property to a variable?
For instance:
?php
class TimePeriod
{
protected $seconds;
protected $minutes;
protected $hours;
public property Seconds read $seconds write setSeconds;
On Mon, 2010-11-29 at 12:18 -0600, la...@garfieldtech.com wrote:
Another advantage here would presumably be performance. If there's
no
getter defined then the engine could simply map $foo-bar to the
class
member directly (which is really fast) and not to a method, so
there's
no added
On 11/29/10 12:41 PM, Johannes Schlüter wrote:
On Mon, 2010-11-29 at 12:18 -0600, la...@garfieldtech.com wrote:
Another advantage here would presumably be performance. If there's
no
getter defined then the engine could simply map $foo-bar to the
class
member directly (which is really fast) and
On Mon, 2010-11-29 at 13:40 -0600, la...@garfieldtech.com wrote:
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
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
Hi !
This is my first email here (I'm just a PHP user, with only very basic C
skills, but I'm working on it), and I would love to contribute to this project.
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
On Sunday, November 28, 2010 5:18:40 pm presid...@basnetworks.net wrote:
Link to the RFC:
http://wiki.php.net/rfc/propertygetsetsyntax
Thanks,
Dennis Robinson
This is a very well-written and well-thought through RFC, Dennis. Nicely
done.
That said, I am not yet convinced. :-)
First of
hi,
Great job, very well written proposal.
Quick notice: the readonly keyword work without being used with a
method (or the default getter/setter):
class A {
public readonly propro;
}
The writeonly property (useful from time to time) is not supported by
default but using the custom
Hi,
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 {
/**
*
*/
93 matches
Mail list logo
