Re: consistent way to handle structs

On Fri, 11 Jan 2002, Markus Fischer wrote: > On Fri, Jan 11, 2002 at 11:22:22AM +0100, Hartmut Holzgraefe wrote : > > Georg Richter wrote: > > > > >is there (should be) a consistent way to pass or return a structure?! > > > > > >e.g.: > > > > > >a) Function mktime splits the structure in lot of parameters > > >b) fstat returns a non assoc array > > >c) dio_fstat (which seems to be identical to fstat) returns an assoc array > > > > assoc array IMHO > > > > especialy mktime() is a good example on how *not* to things > > as not everyone in the world is used to month-day-year dates :( > > I'm for (+1) assoc return values. > > I think the code which is used to handle it is more verbose > then ( $day = $assoc['day']; and not $day = $arr[0]; or > whatever) and it also helps debugging because you can just do > a print_r() on the return type. > > > If we start to agree on assoc params we should also think of > new functions to more easily parse them to expected variable > types > > zend_parse_parameters_hash(hashtable TSRMLS_CC, > " key1:type1, > |optional_key2:type2", > &var1, &var2); > > Ok, don't sue me, its just an idea how to simplify those kind > of param-parsings. Zak and I were also discussing about such > a way of parsing more optional argument after his recent > mysql propose. > > Maybe Andrei has an idea too? Andrei had this in mind when he implemented the zend_parse_parameters() framework. I was very much against this because it will encourage people to write functions who's parameters are hashes. This would lead to a huge performance hit (both the building of the hash before it's sent and the fetching of the various sent fields) and therefore I think it's a very bad thing to introduce. As it'll be so easy to use it'll encourage passing parameters in hashes which is something we really wouldn't want. Andi