Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50765
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=HHA9TQlHRIHqzXUkcWxhu/e7xTpXaF4XPw/QsKmNvlB1lDCiUqa1eoxIAuND374ldd
         zwTxUr5Zr44Y02flFqprBgN7rWpsF5XDGcMrO8QFtFtSsSfVwA3FGCgJco15Ivry+GVd
         av4Arpe2ckrq3dZnSq6CammDVPOa72OMGiDSQ=
MIME-Version: 1.0
In-Reply-To: <AANLkTinEne8Rq-Ew+=GsC_DF0x8D0FP8XmjRB_txpQXE@mail.gmail.com>
References: <ae7aa0536c47a2ac725222d49918183f.squirrel@webmail.basnetworks.net>
	<003601cb8fd0$f6494e80$e2dbeb80$@com>
	<4CF3B855.5010406@sugarcrm.com>
	<003401cb8fee$1be39840$53aac8c0$@com>
	<2450924ae03481f5b1382a7f00e5743d.squirrel@webmail.basnetworks.net>
	<4CF50245.5020807@sugarcrm.com>
	<ed0a2b6089e32bc3def3c14a1f510246.squirrel@webmail.basnetworks.net>
	<4CF5118B.2030300@sugarcrm.com>
	<1faa4c3db62771335db714507ac2adfa.squirrel@webmail.basnetworks.net>
	<4CF613EB.40200@sugarcrm.com>
	<AANLkTi=okFXPw6=0p0mPK5LCAzh_-65uZpD13-C6rfJA@mail.gmail.com>
	<AANLkTinEne8Rq-Ew+=GsC_DF0x8D0FP8XmjRB_txpQXE@mail.gmail.com>
Date: Wed, 1 Dec 2010 11:35:09 +0100
Message-ID: <AANLkTikX6RXPnpZcBGXC8S6zG1i96MhL_VZREvj65=Fd@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=000e0cd179c80bf000049656dc7d
Subject: Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
From: eloybote@gmail.com (Eloy Bote Falcon)

--000e0cd179c80bf000049656dc7d
Content-Type: text/plain; charset=ISO-8859-1

2010/12/1 Eloy Bote Falcon <eloybote@gmail.com>

> 2010/12/1 Richard Quadling <rquadling@gmail.com>
>
>  On 1 December 2010 09:22, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>> > Hi!
>> >
>> >> Its not a matter of consistency - Properties, as a cross-language
>> concept
>> >> are not meant to work that way.  You need to think of a property as a
>> set
>> >
>> > Meant by whom? Is there some law of universe that prevents us from
>> > implementing the feature?
>> >
>> >> of two methods that just have a pretty syntax.  Methods cannot be
>> unset,
>> >> and nor should properties be allowed to.  isset() should simply tell us
>> >> whether a property with the specified name is part of the class or not.
>> >
>> > If you need methods, why not use methods? If you mimick object
>> properties,
>> > however, it makes sense to make them work exactly like property,
>> otherwise
>> > you have to explain why they don't work this way.
>> >
>> >> isset() in the way you suggest would just be confusing.  It would allow
>> is
>> >> to say that a property does not exist, when in fact it does exist.
>>  This
>> >> is not logical.
>> >
>> > Sorry, from your answer I don't understand - what happens when you call
>> > isset($foo->property) and unset($foo->property)?
>>
>> If we think of properties as this new entity for the language (rather
>> than somehow massaging existing entities to fit a new usage scenario),
>> then
>>
>> isset($instance->property) will always return true for any defined
>> property. Even if the getter would return null. This is new behaviour
>> and can be easily documented. isset() for a property is more like
>> method_exists() than isset() on a variable.
>> With regard to unset($instance->property), from the manual ...
>>
>> "The behavior of unset() inside of a function can vary depending on
>> what type of variable you are attempting to destroy."
>>
>> So, we already have differing behaviour based upon context. Attempting
>> to destroy a property should through a non fatal error.
>>
>> One idea I had was to keep just the get/set property methods and add
>> to them an additional parameter ...
>>
>> <?php
>> public $seconds {
>>        public set($value, $unset = False) {
>>                if ($unset) {
>>                        // unset() has been called on the property.
>>                        // In this instance $value will be Null.
>>                } else {
>>                        // set the property using the supplied $value.
>>                }
>>        },
>>        public get($isset = False) {
>>                if ($isset) {
>>                        // isset() has been called on the property.
>>                        // If the value is a non-destructive calculation
>> then maybe
>> returning the comparison of the result of the calculation to null.
>>                } else {
>>                        // return the value for this property.
>>                }
>>        }
>> };
>>
>> So,
>>
>> isset($instance->property) would call $instance->property->get(True);
>> unset($instance->property) would call $instance->property->set(Null,
>> True);
>>
>> This keeps just the 2 property methods. It still allows isset/unset
>> and allows the developer the option of handling them.
>>
>>
>>
>>
>> --
>> Richard Quadling
>> Twitter : EE : Zend
>>
>> --
>>  PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> Why change the expected behavior of isset? If a property has not been set
> then isset must return false, and that includes $foo->name = NULL.
>
>
> Regards.
>



Oops, the mail has been marked has spam because of some URI.


Regards.

--000e0cd179c80bf000049656dc7d--