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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
