Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.192 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=YNwGophNy6+xd1MaFfEIxvcCoc2vdnYwzHleMvvUg+ZnXjOTHpLwAH4lQDsz/oLa6LLFDPJzUROcgViYDwB0NJcsqDRvw6Sh/QAaK6A8SoRoiauT3qE8kyY+Vi8eiBnmnI3P9AHkdvGQhymq8FTonbVRlytpciR0AAczmxBp/3g=
In-Reply-To: <454E2E20.6090909@cschneid.com>
References: <005e01c6ff82$e6092c30$ec01010a@intranet.db> <2FAA3BA3-283C-445D-9648-70C207FF2251@prohost.org> <454CBD65.5040205@cschneid.com> <B990B08B-20E3-41FD-BA54-A8F78443B572@prohost.org> <454D66C4.2090708@cschneid.com> <303397962.20061105053913@marcus-boerger.de> <454D6EDE.60202@cschneid.com> <F8692559-650E-4D6C-91F8-F6059700EDDE@prohost.org> <454E2670.4050806@cschneid.com> <9FF4D6D2-2F94-46AA-B13A-75F51C95892A@prohost.org> <454E2E20.6090909@cschneid.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <1C679F79-2C5F-4B0A-A60D-4D143E65E7F8@prohost.org>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Sun, 5 Nov 2006 13:44:38 -0500
To: Christian Schneider <cschneid@cschneid.com>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] New Datetime class problem
From: ilia@prohost.org (Ilia Alshanetsky)


On 5-Nov-06, at 1:32 PM, Christian Schneider wrote:

> Ilia Alshanetsky wrote:
>> There are no "rules" there is just one rule, that's not even  
>> specific to PHP when you think of it. It is generally considered  
>> to be a good practice to prefix your code with app name or similar  
>> to avoid conflicts with other libraries and/or applications. When  
>> it comes to this rule, I think it is one of the very few that are  
>> essential for developers to learn.
>
> What about "do not trust user input"? Or "avoid copy/pasting code,  
> refactor instead"? Or "use descriptive identifiers"?  Those are all  
> rules to be followed when programming. And the more there are the  
> more experience it takes to not get any of them wrong.

And your point is what? There are even more rules you need to obey  
while driving a car, when people forget those rules they often get  
into accidents. Same with programing, there are rules, you can choose  
to ignore them, but don't complain when your code is exploited  
because your didn't check your input or stopped working when an  
namespace you've been mis-using gets taken over by the language.

>>> This would mean classes should be prefixed by extension name...
>> That is the common case, yes. In fact the date extension's classes
>> follow this convention to the letter. DateTime + DateTimeZone (Date
>> is the extension name).
>
> Well, almost: DateTime is a date class, not a time class.

Actually it works with both date & time and calling it datedate seems  
rather silly. I am not going to waste more time arguing about  
DateTime, this has already been covered numerous time, if you got  
time to waste go read internals archives.

>> However, for native classes there maybe exceptions to simplify usage,
>> when a need for such exceptions arise this will be discussed on  
>> this list.
>
> We're only talking about native classes anyway. And I think not  
> bending the rules simplify usage more than saving a couple of  
> letters. Wasn't that a lesson we learned from functions?

That's your opinion and you are certainly entitled to it, but that's  
just it, your opinion.

Ilia Alshanetsky