[wp-hackers] echo and return

David House dave at xmouse.ithium.net
Tue Jul 27 16:52:59 UTC 2004


> 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:

Because as well as backward compatability, we need to think forward. The number
of template tags is inevitably going to go up as WordPress develops, and we
could very easily end up with twice the amount of functions - now *there's* a
hit on memory.

> - It doesn't bother the non-echoing user with having to write 
> 'echo=false' at every function call.

The what now? Template functions are used as just that -- template functions --
for the large majority of the time. The amount of time a developer (and it's
generally only developers that want to see return values -- Joe User is quite
happy with their templates just existing as templates) needs a return value and
not an echo is quite small. It's not really trouble to include one paramater. In
fact, I'd say it's about the same amount of trouble that it takes a developer to
add in the extra lines to declare a new function.

Other arguments:

* It's intuitive: it does the same job, why should we have two different
functions? This doesn't make sense from the users standpoint.
* Backward compatability isn't really an issue -- we could quite easily create
functions as I said in a previous email [1]. This could be gradually phased out
over time.
* The echo constant is a nice idea but it would need trial: how often does a
developer need to use a non-echoing function? Yeah, it would work if they were
all together in one block, but if they're spread out sparesly, then it would be
a shame to add in two lines setting and unsetting this constant either side of
the function call.

[1]: http://wordpress.org/pipermail/hackers_wordpress.org/2004-July/000872.html

Quoting Brian Meidell <brian at mindflow.dk>:

> 
> 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
> > 
> > 
> 
> 
> _______________________________________________
> 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.




More information about the hackers mailing list