Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38699 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91839 invoked from network); 2 Jul 2008 07:21:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Jul 2008 07:21:32 -0000 Authentication-Results: pb1.pair.com smtp.mail=lokrain@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=lokrain@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.200.171 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: lokrain@gmail.com X-Host-Fingerprint: 209.85.200.171 wf-out-1314.google.com Received: from [209.85.200.171] ([209.85.200.171:9089] helo=wf-out-1314.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C2/CC-10269-B7C2B684 for ; Wed, 02 Jul 2008 03:21:31 -0400 Received: by wf-out-1314.google.com with SMTP id 26so243506wfd.26 for ; Wed, 02 Jul 2008 00:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=5wSNvilpOAwjRpuaPMAzru+H9Q7TScPMmo6lxnmpIwc=; b=Q3k2pB4xSZURhd8T+5h7vldi25Ca1SGVfsrEza/ikwihLPJJzq2BApgiW7ZnILVEps cYAZSVRcSNQ7A6ZlWgC1mkUE2RJNffGyKEHcAIVHyv7dC4hcFvAZbtX8ESgq998q3NST g6eN8rp0NBX9CjkTGXmIwhhfYSDNuc9sNqvUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=AGZAwiC9BJOk3yiqIZM13xkJfmBTzvHkKjE2bNNvU2IylTpEMZmSDePdjmSKgQ1qTa OThMbtbxQcFlKY7LuCj7tX7Vgd1CHevZi3HsA5nvnloThOUaVCXqYrMeK/rxI26WSViG 05O2Yn+GWRWkZTN21ejrUlA8a+fFr7qAvuLdQ= Received: by 10.142.171.6 with SMTP id t6mr2891786wfe.229.1214983288569; Wed, 02 Jul 2008 00:21:28 -0700 (PDT) Received: by 10.142.255.15 with HTTP; Wed, 2 Jul 2008 00:21:28 -0700 (PDT) Message-ID: <345fd5cd0807020021sc2c21bbmed0f1623d76791de@mail.gmail.com> Date: Wed, 2 Jul 2008 10:21:28 +0300 To: internals In-Reply-To: <486ABB59.4070602@zend.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1452_514751.1214983288561" References: <486AB5F5.50400@smashlabs.com> <486ABB59.4070602@zend.com> Subject: Re: [PHP-DEV] Magic method visibility in PHP 5.3+ From: lokrain@gmail.com (Lokrain) ------=_Part_1452_514751.1214983288561 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello there, I don't have enough time to write more detailed example, but I still want to write my opinion. I totally agree with Stanislav, because for me magic functions should be used in last leaf of some class extend tree. They are some kind of feature when you are producing the non-framework, specific project coding stuff. Which mean they should be not encapsulated and invisible. If a developer never intends on a user calling $obj->__set(...), then it > should be allowed that the public call to that method be disallowed, but > still allow the magic functionality (b/c of the presence of that magic > function.) > Giving the "user" ability to call $obj->__set() is just some kind of speed optimization, you just miss the magic thing. Another point of view is that this __set() is still a function why you want to disable the function calls and enable the functionality? B/c of the presence of that magic function? What a drama! This is not fairy world where magic should be wonderful thing which just happens. Think of us (developers) as wizards, who know how/why this magic works! Nothing personal just some thoughts. Regards, Dimitar Isusov ------=_Part_1452_514751.1214983288561--