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
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
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
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()
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
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
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
{
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
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
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
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
Hello,
This is my first time using a mailing list, so please bear with me.
Some time back I suggested that PHP should have a property get/set syntax
similar to that of Microsoft's C# language. One of the PHP developers
suggested that if I were serious about it, I should write an RFC. I have
36 matches
Mail list logo
