Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50779 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86885 invoked from network); 1 Dec 2010 13:58:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Dec 2010 13:58:03 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.143 smtp143.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.143] ([207.97.245.143:42764] helo=smtp143.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AF/84-62427-A6456FC4 for ; Wed, 01 Dec 2010 08:58:03 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp34.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id A48B8B80C4; Wed, 1 Dec 2010 08:58:00 -0500 (EST) X-Virus-Scanned: OK Received: by smtp34.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 0DC373809BB; Wed, 1 Dec 2010 08:57:04 -0500 (EST) Message-ID: <4CF6542A.3070201@sugarcrm.com> Date: Wed, 01 Dec 2010 14:56:58 +0100 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "president@basnetworks.net" CC: "internals@lists.php.net" References: <003601cb8fd0$f6494e80$e2dbeb80$@com> <4CF3B855.5010406@sugarcrm.com> <003401cb8fee$1be39840$53aac8c0$@com> <2450924ae03481f5b1382a7f00e5743d.squirrel@webmail.basnetworks.net> <4CF50245.5020807@sugarcrm.com> <4CF5118B.2030300@sugarcrm.com> <1faa4c3db62771335db714507ac2adfa.squirrel@webmail.basnetworks.net> <4CF613EB.40200@sugarcrm.com> <23d1e573d22236bad96d57ffff4e3001.squirrel@webmail.basnetworks.net> In-Reply-To: <23d1e573d22236bad96d57ffff4e3001.squirrel@webmail.basnetworks.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP From: smalyshev@sugarcrm.com (Stas Malyshev) 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 everywhere. Perl has the same rules, for example. > explain === to them. This is because PHP goes against the defacto > standard. Maybe it would have been better if == and === had the opposite > meaning, as to not squash the standard? There's no such standard. PHP works differently than the language you knew before, that's it. If it worked the same, it would be the same language. > Because properties are only meant to be a pretty syntax for a get/set > method. Thats it! I don't know of any other special behaviour in any > other language that lets you "hide" properties or anything else like that. If that's it, we probably don't need them. They would just hide what happens in the code and confuse the user, which would not know what $a->foo means - would it work according to class attribute rules or class method rules? I think, however, this syntax might be useful - for example, Zend Framework does a lot of property/method linking, some other frameworks do that too, and individual methods might be better than catch-all in this case. But that requires consistency. 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. > You make a good point. If we can't unset a property, than we lose > consistency with regular variables which I guess ruins the point of > properties. It doesn't have to - if we can find a consistent concept of how to do it. But we need to think about it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227