Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84219
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54F57834.4030305@lsces.co.uk>
Date: Tue, 03 Mar 2015 09:00:36 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: OO the PHP way ...
From: lester@lsces.co.uk (Lester Caine)

One proposal that is being presented in several guises is the idea of
scalar objects with a clean interface to use those objects. This allows
a complete new API without needing to touch any of the 'legacy' system
names. Introduce a graphics interface as an object as an alternative to
gd and the like. We already have datetime (although I now expect a
demand to change it's method names?) so completing the compliment of
objects would make sense.

But are we simply missing a trick here? For those who want a more strict
control of variable types why not make the base for all scaler objects
'variable' ... this will handle all of the details such as name and
allow restrictions to be added such as 'int' or 'float' but still
leaving the more flexible view if that is not defined.

I keep coming back to my as_xxx as the proper way to put strict limits
on things when actually using any object, so passing a variable to a
function where one wants a strict type match rather than $var, use
$var->as_int ? I've not fully thought this through so someone who is
more into static typing might have an much more appropriate alternative?

I keep looking mind  at all this 'debate' just in time compiling and all
the rest, but to mind the library of functions to handle objects already
exists and has been compiled, so if the function we are trying to access
already exists and is compiled using integers for it's inputs, that we
only want to pass integers is fine. This is in some way heading towards
the python 'pre-compiled' libraries and I am not sure THAT is the right
approach?

Michael quoted
> I can't think of any good use case for a bulk import outside of laziness.
But if that library is already compiled and loaded?

I will bang on about ADOdb because it is still one of the few generic
database abstraction layers and at one time it had a pre-loaded
extension providing the core functions. I still find that the right way
forward, with pecl providing specialised builds of function libraries,
while PEAR provides a more boiler plate library of fine detail.

I build a version of PHP that suits my requirements and omit those
secondary extensions I don't use but perhaps with a load mechanism that
allows third party tools to temporarily add missing functionality.

-- 
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