>> > 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:
>>
>>
> On 5 December 2010 16:47, 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 a
On 5 December 2010 16:47, 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 really for.
Hi Dennis
2010/12/6 :
> 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 done, but I'm not sure h
>> 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
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.)
>
> Wel
Hi Dennis
2010/12/5 :
> 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 b
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 th
>>> 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 yo
>> 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 lang
> 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
Ok, sorry for the buzz, have to re-read it then to catch up.
2010/12/3 la...@garfieldtech.com :
> On 12/3/10 7:12 AM, Arvids Godjuks wrote:
>
>> I'm sorry if in last 10-15 emails there was any change to better
>> understanding the PHP, I just didn't follow any more. I'm sorry if I
>> offend you in
On 12/3/10 7:12 AM, Arvids Godjuks wrote:
I'm sorry if in last 10-15 emails there was any change to better
understanding the PHP, I just didn't follow any more. I'm sorry if I
offend you in any way by this e-mail, but really... I think it has to
stop. Don't push features witch are inconsistent w
On 3 December 2010 12:53, wrote:
>> On 2 December 2010 13:51, wrote:
2010/12/1 Richard Quadling
> On 1 December 2010 09:22, Stas Malyshev
> wrote:
>>> ...
>>>
Why change the expected behavior of isset? If a property has not been
set
then isset must return fals
Hi Dennis!
Could you please stop trying to push the feature like it is in C#? PHP
is a different language, with absolutely different purpose and with
it's specifics - both as historically and based on it's purpose as a
WEB development language.
I admire your passion, but really, the amount of e-ma
> On 2 December 2010 13:51, wrote:
>>> 2010/12/1 Richard Quadling
>>>
On 1 December 2010 09:22, Stas Malyshev
wrote:
>> ...
>>
>>> Why change the expected behavior of isset? If a property has not been
>>> set
>>> then isset must return false, and that includes $foo->name = NULL.
>>
>>
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 impl
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 havi
On 2 December 2010 13:51, wrote:
>> 2010/12/1 Richard Quadling
>>
>>> On 1 December 2010 09:22, Stas Malyshev wrote:
> ...
>
>> Why change the expected behavior of isset? If a property has not been set
>> then isset must return false, and that includes $foo->name = NULL.
>
>
> Thats simple then
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 l
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
> 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,
> 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, becau
> 2010/12/1 Richard Quadling
>
>> On 1 December 2010 09:22, Stas Malyshev 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 so
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 I
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
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
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.
>> 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 s
>> 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?
I
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 laye
On Wednesday, December 01, 2010 8:47:50 am presid...@basnetworks.net wrote:
> > 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,
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 differe
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 eve
On 2010-12-01, Arvids Godjuks wrote:
> You are missing the point in PHP in that case. Because PHP is dynamic
> scripting language, public properties can be added and removed in the
> object on the fly. That's why there is isset and unset that works on
> object properties. Consider ActiveRecord, D
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
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(
Hi Larry,
>>> First of all, I have generally found the Bean-style getter/setter
>> approach to
>>> be a sign of poor encapsulation to begin with. You shouldn't be
>>> mucking
>> with
>>> internal elements of an object in the first place, period. More
>>> details on
>>> that here:
>>>
>>> http://
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 exampl
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
> u
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 functional
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 e
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 s
>> 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.
Y
>> 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 ther
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
>>>
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 s
On 1 December 2010 12:30, Stas Malyshev wrote:
> Hi!
>
>> No. The prototype of all setters would be the same. As would the
>> prototype of all getters.
>
> But we'd have two sets of properties - one handled by __get/__isset, another
> - by get($isset). Not a good idea.
So, should properties isset
Hi!
No. The prototype of all setters would be the same. As would the
prototype of all getters.
But we'd have two sets of properties - one handled by __get/__isset,
another - by get($isset). Not a good idea.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)45
On 1 December 2010 10:38, Stas Malyshev wrote:
> So we have one set of properties where get and isset use different methods
> and another set of properties where get and isset use same method but with
> parameter. I think it's not the best way to go. It's better to ignore isset
> altogether than t
On 1 December 2010 10:23, Eloy Bote Falcon wrote:
> 2010/12/1 Richard Quadling
>>
>> On 1 December 2010 09:22, Stas Malyshev 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 pr
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.
Hi!
If we think of properties as this new entity for the language (rather
than somehow massaging existing entities to fit a new usage scenario),
then
I think the idea of new entity of the language looking exactly like old
entity of the language but having different rules is kind of non-starte
2010/12/1 Eloy Bote Falcon
> 2010/12/1 Richard Quadling
>
> On 1 December 2010 09:22, Stas Malyshev 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
>> >
>>
On 1 December 2010 09:22, Stas Malyshev wrote:
> Hi!
>
>> Its not a matter of consistency - Properties, as a cross-language concept
>> are not meant to work that way. You need to think of a property as a set
>
> Meant by whom? Is there some law of universe that prevents us from
> implementing the
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.
--
Hi!
Its not a matter of consistency - Properties, as a cross-language concept
are not meant to work that way. You need to think of a property as a set
Meant by whom? Is there some law of universe that prevents us from
implementing the feature?
of two methods that just have a pretty syntax
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:
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
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 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
> 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
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 muc
>> 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
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 th
>> 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
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"
>> 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 i
> ...
>
>> /**
>> *
>> */
>> 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 what
> 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 fi
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 :
>
> class TimePeriod {
> protected $seconds;
> protected $minutes;
> protected $hours;
>
>
> @synthesize (rea
>> 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
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
On 30 November 2010 12:48, 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
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 wh
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
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 t
2010/11/29 Ángel González :
> 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
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
ti
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 nec
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"
>> >
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
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 this
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 shoul
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 m
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 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 a
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:
= 0&& $seconds< 60) $this->seconds = $seconds;
}
public function setMinutes($minutes)
{
if ($minutes>= 0&& $minutes< 60) $this->minutes =
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. sea
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 i
2010/11/29 Ángel González :
> Richard Quadling wrote:
> setMilliseconds() should have $value as parameter instead of a magic name.
>
> What about allowing this syntax to attach the property to a variable?
>
> For instance:
>
> class TimePeriod
> {
> protected $seconds;
> protected $minutes;
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. woul
On 2010-11-29, Stas Malyshev 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 be "set"
On 2010-11-29, Richard Quadling wrote:
> On 28 November 2010 23:18, 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 clos
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 ar
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;
On Sun Nov 28 06:18 PM, presid...@basnetworks.net wrote:
>
> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
>
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 =
On 28 November 2010 23:18, 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 in Delphi and I alway
On Sun, Nov 28, 2010 at 11:48 PM, Christian Kaps
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;
> }
>
> G
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 {
/**
*
*/
ge
1 - 100 of 103 matches
Mail list logo
