You can continue to use arrays for database records like you always have been. None of the new or proposed features are going to stop you.
The concept of type annotations and type systems really has nothing to do with databases directly. It's about adding certainty with regards to the types that are flowing through your PHP program so the program can be modified reliably and predictably. A database is just one possible thing *outside* the program to connect to and interact with using some protocol. Creating a mapping between database records and types PHP objects and types in order to leverage PHP's type system for the purpose of using a databases is quite a complex topic in and of itself, but basically amounts to using some kind of object-relational-mapper such as Doctrine. However, I'm not sure how recent or proposed improvements to typing is related. All I can think of is that Doctrine could make use of type properties instead of PHPDocs for getting column types. You can also just continue to arrays, or a simple class with get($column) and set($column, $value) methods. That's what I do. :P On Thu, Apr 21, 2016 at 5:22 AM, Lester Caine <les...@lsces.co.uk> wrote: > With all of the debate on the 'type system', can I just ask a probably > silly question ;) > > I'm currently working on porting an application that has been running on > windows as C++ code for 20 years. The main reason for changing is that > While it worked fine when sites upgraded to XP, the move to W7 and later > really needs all the code recompiled, something that will need a big > cheque book to buy a current compiler set. So for many reasons a switch > to web based using already existing tools makes perfect sense. > > The database is still running Firebird since the switch from interbase > in the late 90's so all of the existing data can be maintained, and I > already have a working base on which to build a new set of page > templates. ( Only hole is the need for a decent javascript scheduler > function to replace the desktop one :( ) > > This is all running on SQL based schema's which have not changed in > years, and ADOdb still quite happily produces arrays of results for > which there is little point creating new 'objects', just simply handling > the basic variable entries in the arrays just as I have for years. The > various tools handle data validation, and 'null' is an essential > component of that validation process. This does not need any of the > overload of creating 'getters and setters' and I see little point trying > to add any 'type' casting into the process since the validation layer > simply works with the bog standard variables without and need for > 'special cases'. > > So what benefit does all of the additional 'facilities' now being piled > on give that would actually improve that process. I am now seeing a > speed improvement on the PHP7 ports, but I'm not seeing any point to > make any changes to code OTHER than making the PHP5.2 code clean on PHP7 > ... As Zeev has already said "PHP is not broken" ... Do I really need to > change the way I work which is running fine for my clients? > > -- > 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 > >
