Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:709
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Fri, 4 Apr 2003 23:02:58 -0800 (Pacific Standard Time)
To: Per Lundberg <per@nobolt.com>
cc: jay@php.net, internals@lists.php.net
In-Reply-To: <1049476671.28232.629.camel@salem.intra.nobolt.net>
Message-ID: <Pine.WNT.4.53.0304042252560.1060@DELL>
References: <20030404145236.GA32691@hyperion.gravitonic.com> 
 <1049469044.6067.1.camel@hasele>  <Pine.LNX.4.53.0304041731210.14396@jdi.jdimedia.nl>
  <20030404160719.GB1558@hyperion.gravitonic.com> 
 <1049475676.28232.615.camel@salem.intra.nobolt.net>  <20030404170639.10192.qmail@pb1.pair.com>
 <1049476671.28232.629.camel@salem.intra.nobolt.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Static and non-static methods
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On Fri, 4 Apr 2003, Per Lundberg wrote:

> On Fri, 2003-04-04 at 19:06, J Smith wrote:
> > It's been said before, but PHP isn't C++ or Java, so why would they have to
> > be compatible?
>
> Because it will make it easier for C++ or Java programmers to find PHP a
> pleasant experience.

Only the people looking for purity and aesthetic beauty.  I hate to break
it to you, but PHP is an ugly language.  It is always going to be an ugly
language.  Ugly problems often need ugly solutions because the pretty
solution is sometimes just too much of a hassle for everyone involved.

There are many examples of this uglyness.  Case-insentive function names
is one, you are arguing that this is another.  But look at it from the
real world and not from the purist looking for beauty.  Does it really
matter that you can't make two functions that only differ by case?  Are
you really going to have foo() and Foo() in the same code doing different
things?

Along the same lines, why do you care if you can call a static method in a
class without declaring it static?  Other languages, or some CS prof
somewhere told you it was uncool, but so what?  It isn't going to change
the way your code runs or the way anybody uses the language.

If we were starting from scratch at this point, sure, some of these things
would be done differently, but we have a bunch of legacy code out there,
and when choosing whether to break backward compatibility we need to look
long and hard at why we are doing so in each case.  If the only answer is
for purity or aesthetic beauty reasons, we are very likely to always
choose the uglier BC road.

-Rasmus