On 27/05/16 18:25, Rowan Collins wrote: > On 27 May 2016 10:53:05 GMT+01:00, Lester Caine <les...@lsces.co.uk> wrote: >>On 27/05/16 10:16, Rowan Collins wrote: >>> The most useful typehints are inside the SomeModel class, not the >>> table-level wrapper. This is true even if they're just dumb structs, >>and >>> all the behaviour is at the table level, because it presumably has >>> basically one field: array $data. >> >>Probably the only difference here is that '$row' in my result set is >>not >>a dumb structure. It has type information, field lengths and >>potentially >>even value constraints. > > Do you mean it "has" that type information because it's guaranteed by > other logic? Or is $row already an object, in which case we're saying > the same thing?
As there is no current way of adding type information to the elements of an associative array one has to manipulate http://adodb.org/dokuwiki/doku.php?id=v5:dictionary:adofieldobject to obtain the missing information. ADOdb will also return the row as an object http://adodb.org/dokuwiki/doku.php?id=v5:reference:recordset:fetchobj and I have been trying for 15+ years to make that work with the type data we have always had here. The important thing to note here is that rather than having a pre-defined set of fields with pre-defined types, the result set can be controlled by what is returned by the database! While a 'built in' object would have to define every possible filed that might be used. I know that we have had differences in the past on 'well defined data', and I do accept that providing a fixed set of fields would be a preferable way of working, but being able to take a flexible result set and provide a clean fully typed object from it should not be difficult? >> So my table level wrapper can potentially have >>the same typehints that you are then adding to SomeModel. > > An object holding 20 people has no "date of birth" property, so how can > it have a typehint for it? An object representing one row of the table > can, and that's what most of the examples here are talking about. My initial query will establish the tree of people available in the database, and just what data fields are available. Some fields are 'required' such as 'dateofbirth' which are by definition a DateTime type but wild card results will add additional fields. > I think maybe we're just talking cross-purposes - my example was a > clumsy way of saying that *somewhere* the raw data coming back from the > DBMS driver gets converted to an appropriate object. ADOdb will return a fully formed object containing it's set of data if we get the way of handling typed 'variables' sorted properly! The 'person' object simply becomes a database query return ... and no secondary copying is needed. > The main point was that that conversion doesn't need some pool of empty > objects to "fill up" with data, it just creates a new object for each > row in the result set. My 'empty pots' are more related to rendering the displayed page. I can see where my terminology is perhaps wrong, and perhaps a different way of handling things which in the past have been easy as associative arrays with null elements. It's being able to pick up just what validation is needed on the page for those empty inputs which needs more than a null object? The empty pot has all of the type/attribute information ... -- 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
