Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:5823 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35116 invoked by uid 1010); 30 Nov 2003 11:38:52 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 35091 invoked from network); 30 Nov 2003 11:38:51 -0000 Received: from unknown (HELO shiva.mind.de) (212.42.230.204) by pb1.pair.com with SMTP; 30 Nov 2003 11:38:51 -0000 Received: from [192.168.1.100] (p508EB77C.dip.t-dialin.net [80.142.183.124]) by shiva.mind.de (Postfix) with ESMTP id 60D3997C5F; Sun, 30 Nov 2003 12:38:45 +0100 (CET) Date: Sun, 30 Nov 2003 12:38:46 +0100 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <149669835296.20031130123846@marcus-boerger.de> To: "Ferdinand Beyer" Cc: internals@lists.php.net In-Reply-To: <3FC9C98C.1182.31C2AB@localhost> References: <3FC9C98C.1182.31C2AB@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Naming convention for build-in classes and interfaces From: helly@php.net (Marcus Boerger) Hello Ferdinand, Sunday, November 30, 2003, 10:42:20 AM, you wrote: > Hello everyone, > I think we have reached a point where we should really consider a > naming convention for build-in classes and interfaces. In my opinion, > popular class names like "exception", "iterator" or "directory" should > be left to user land. An exception is more or less a language construct and we need a base exception which can do all the general things which you cannot accomplish at userland so the internal one is called exception. If i would name it BaseException then i would expect that it is nowhere used and derive a class Exception internally to use where we throw exceptions. For the other names: OO is about code reuse so the common things should either be done in pear, in an extension or in the engine so that anybody can take advantage of good tested code without the need to reinvent the wheel anytime. If you feel the need that the common solution doesn't really fit your needs, well then you have discovered the other aspect of oo programming which is specialization for specific needs. And hence only a few tiny changes/specializations are needed. > Moreover we should make more use of interfaces for magical OO > behavior like cloning, casting, serializing and overloading. > Therefore my suggestion is to introduce following symbols: > - class php_object instead of stdclass, since (object) $var represents > an object and not a class. It is more meaningfull to create a new > php_object() instead a new stdclass() Sounds logical, but i'd like phpObject more. > - class php_exception instead of exception > - interface php_cloneable for classes implementing the __clone() > method > - interface php_serializeable for classes implementing __sleep() and > __wakeup() > - interface php_overloadable for classes implementing __get(), > __set() and __call() > Maybe there is a better prefix than "php" to strictly separate Zend > Engine from PHP. Examples are "zend_xxx", "zxxx" or "__xxx". Too many magical feetures is bad because it is hard to understand. Best regards, Marcus mailto:helly@php.net