Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6257
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <3FD20AAE.30909@hristov.com>
References: <5.1.0.14.2.20031203223915.02f7fb00@127.0.0.1> <200312061001.hB6A1E8M032486@mailserver3.hrz.tu-darmstadt.de> <20031206161404.GA13130@prp0.prp.physik.tu-darmstadt.de> <8F46C0C1-280B-11D8-B53A-000393B2B3C0@omniti.com> <3FD20AAE.30909@hristov.com>
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <981AB96A-280E-11D8-B53A-000393B2B3C0@omniti.com>
Content-Transfer-Encoding: 7bit
Cc: internals@lists.php.net
Date: Sat, 6 Dec 2003 12:06:55 -0500
To: Andrey Hristov <php@hristov.com>
Subject: Re: [PHP-DEV] StudlyCaps
From: george@omniti.com (George Schlossnagle)


On Dec 6, 2003, at 11:58 AM, Andrey Hristov wrote:
> It's hard but not impossible to extend internal classes. The 
> workaround is to write thin wrappers with the studlyCaps convention 
> which only just call the methods in their parents like 
> INTERNAL_FUNCTION_PARAM_PASSTHRU. After then comes the real class that 
> extends the functionality by extending the wrapper. So if another 
> class extends the latter it does not have to know that the top into 
> the hierarchy is an internal class that uses different naming 
> convention. Anyway, this is an way to workaround, not completely clean 
> but can help.

This whole issue is non-technical and purely stylistic.  Neither 
outcome would keep anyone from achieving anything, it may just make 
life more difficult for the PEAR folks.

George