[wp-hackers] echo and return

[Brian Meidell]

Another possibility is to make all the echoing functions also return the 
value, and make them respect a global echo parameter. This way you can 
turn off echo for the section you are working on and get return values.

But really: What is the problem with having a get_ method and an echoing 
partner for it? It's a perfectly sane way to do it in my eyes:

- It's not harder for the developer to create the extra function that it 
is to create the branch inside the function (it's the same).
- It's not slower (in fact, it's insignificantly faster)
- It doesn't bother the non-echoing user with having to write 
'echo=false' at every function call.
- And it's entirely backwards compatible - unlike the parameter 
approach. You can make the original function honor the echo flag and 
leave it in there for backward compatability, but you can't do it the 
other way around.

What is it you don't like about having two functions?
I don't understand it.

/Brian

David House wrote:

> Can we bring this discussion back on track? URI-style or traditional-style
> parameters, I don't mind, but we need to decide how we're going to manage
> echoing and returning. Personally, I'm a fan of getting rid of all the
> get_the_* functions, just having the_* functions and passing everything
> URI-style (yes, I realise this is rather different to my previous view, but
> I've changed my mind).
> 
> So all the logic goes into the the_* functions, and every function needs to
> respect an 'echo' parameter. Eg, calling the_date('echo=0'); would return the
> date of $post, formatted as of get_settings('date_format');.
> 
> Quoting Brian Meidell Andersen <brian at mindflow.dk>:
> 
>>*Foundation shaking*
>>
>>Well, I stand corrected then. You have more experience in the support area.
>>
>>I can see how it might have it's use, if you want to make single 
>>function call plugins that can have all kinds of things configured.
>>I can also see how it helps migration.
>>
>>Personally, I wouldn't like to see everything turn into url parameters 
>>though.
>>Calls that the user is exposed to should be consistent, and if we had to 
>>make even simple functions into url parameters, I think it get's real ugly.
>>
>>But I'll bend to the will of the crowd. I think it's important to agree 
>>to work according to a common style - naming and calling conventions 
>>especially - and follow it.
>>
>>So what does the crowd think?
>>
>>/Brian
>>
>>Kitty wrote:
>>
>>
>>>On Mon, 2004-07-26 at 14:53 +0200, Brian Meidell wrote:
>>> 
>>>
>>>
>>>>About the url encoded parameter lists, though:
>>>>Since user friendliness seems to be an issue (an approach I agree with), 
>>>>I can't understand why we would go with url encoded argument strings.
>>>>
>>>>I can't think of anything much more user hostile than asking the user 
>>>>not only learn the parameters for the method, but also the name of the 
>>>>parameters, and then try to get the encoding right.
>>>>
>>>>I will would be shaken at my foundation if users weren't more confused 
>>>>by url encoded parameter lists than either $echo parameters or double 
>>>>functions.
>>>>   
>>>>
>>>
>>>Prepare to have your foundation shaken. 
>>>
>>>One of my plugins, "Show Categories" is pretty widely used. If someone
>>>wants a mini-blog in a side bar, they either use this, or Matt's asides.
>>>Somewhere around the second release, I was was in param list hell. So I
>>>went to the 'url' style param list. 
>>>
>>>I've not had *one* support request/feedback asking how to use it! And
>>>with the nature of the plugin you *have to* pass params. 
>>>
>>>Some of the functions that most widely modified in #menu also take 'url'
>>>params, and tend not to be a problem for users. It's a fairly intuitive
>>>way of passing params, believe it or not. The users can see exactly what
>>>they're setting, and don't have to worry about the positional aspect.
>>>
>>>So don't underestimate the users. Don't develop for "grandma," as a lot
>>>of people in the open source world are. I try an stick with this
>>>assumption:
>>>"Anyone interested in customising their blog will be able to digest the
>>>the few technical bits that are needed to make things work. So document
>>>accordingly."
>>> 
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>hackers mailing list
>>>hackers at wordpress.org
>>>http://wordpress.org/mailman/listinfo/hackers_wordpress.org
>>> 
>>>
>>
>>_______________________________________________
>>hackers mailing list
>>hackers at wordpress.org
>>http://wordpress.org/mailman/listinfo/hackers_wordpress.org
>>
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 
> 
> _______________________________________________
> hackers mailing list
> hackers at wordpress.org
> http://wordpress.org/mailman/listinfo/hackers_wordpress.org
> 
>