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? > 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. 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. 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. -- Rowan Collins [IMSoP]
