On Fri, Jan 11, 2002 at 12:58:44PM +0200, Andi Gutmans wrote : > 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.
What other way do we have to specify arbitray optional parameters without an ordering? Teh disadvantage of optional parmeters is when you need to only set the last one, you'll have to define all preceding optional parameters too. For functions like mysql_connect() the performance impact is negligible (methinks). > As it'll be so easy > to use it'll encourage passing parameters in hashes which is something we > really wouldn't want. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]