Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62845
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.185 cause and error)
Message-ID: <5048534F.6020303@lsces.co.uk>
Date: Thu, 06 Sep 2012 08:39:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <5045AA9B.5080703@sugarcrm.com>
In-Reply-To: <5045AA9B.5080703@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] On BC and interfaces
From: lester@lsces.co.uk (Lester Caine)

Stas Malyshev wrote:
> Given many discussions on the list about changing stuff in PHP, I'd like
> to bring everybody's attention to comment by Linus Torvalds in this
> topic:https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk

> It talks about Linux kernel and discussion has next to nothing to do
> with PHP, but generic point about keeping the interfaces and importance
> of not serving one use case I think very important for all widely used
> platforms equally. I think the opinion of the author of one of the most
> successful platforms in recent history may be interesting to consider.

To quote ...
Some gnome people seem to be in total denial about what their problem really is. 
They'll wildly blame everybody except themselves. This article seems to be a 
perfect example of that.﻿

In addition to managing all of the changes being integrated into PHP I've been 
living with the 'improvements' in Linux. KDE3 became KDE4 and in my opinion 
totally unusable! OK I'm a dodo, but simply LEARNING how to cope with a new way 
of working and fighting a deliberate policy of blocking any 'classic' theme ... 
I moved over to Gnome which did at least work more like I was comfortable with, 
and they go and do the same pigging thing! But at least someone was listening 
and I'm on a 'classic' view currently. Progress needs to be productive not 
aesthetic?

How does this relate to PHP? It's exactly the same attitude here. SPL interfaces 
are something we can currently take or leave. Personally I'd just disable them 
altogether but it seems I can't? Some would like to force them on us, and 
generators are a nail now to hang making more stuff 'core' such as more 
exceptions. But personally I don't need them. All of my persistent storage is 
via the database, and fast access to that - filtering the information required - 
processing the output - purely uses the database interface. PDO gives me nothing 
there. It's still incomplete and there is little interest in 'completing' it. 
ADOdb may be a bit bloated, but a bit more attention to the extension from those 
of you who understand the fine detail and we could have a faster well 
established alternative? Currently each major project is going of designing it's 
own alternative some based on PDO, some database specific, simply because there 
is not a GOOD standard interface to work off. Even the ZendDB interface ends up 
getting it's own custom extensions on each project making maintenance a 
nightmare. I've three different zend framework based sites I've inherited and 
all three provide a 'different' database interface! They will be moved to my own 
framework simply because it's easier than trying to learn three new methods of 
working. That and I can get everything back onto Firebird which provides 
transparent background backup's.

The drive to release more often has to have a 'reason'. And getting bug and 
security fixes out promptly is the reason, not trying to placate some self 
inflated commentator who says "PHP is crap because it doesn't have ..." but they 
are never going to use it anyway?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk