On Jan 29, 2007, at 5:06 AM, RonPiterman wrote:
Wow - thanks for the full coverage response !
No problem, thanks for reading the whole thing. I've obviously spent
way too much time thinking about this ;)
You did convince me, except for one thing:
You know this game "the incredible machine", where you have to
setup some items so that a ball will fall down and create a domino
effect? I think whenever programming becomes like that, things are
going in the wrong direction.
What do I mean by that?
When desining an API, you have to be very clear, now would you
like using this method in an API:
/**
* renders the component.
* if renderTag is null, tag will be rendered
* unless tag is "div" or "span", in which case no tag
* will be rendered.
* if rendertag is not null, tag will be rendered depending on
* the boolean value of the renderTag argument
*/
renderComponent( String tag, Boolean renderTag );
ouch.
Agree completely. I don't think the renderTag parameter and tag-
dependent rendering can coexist in a useful way. The logic I'm
suggesting is:
- if 'element' is not null, render the specified tag (I'm talking
about the deprecated element parameter here)
- otherwise, render the template tag if it's anything but div or span
The logic you're describing assumes that renderTag is a Boolean
object, but it's currently a primitive (with the default determined
by the renderTags property, which is configurable at multiple
levels). Making renderTag a Boolean object and letting it default to
null would at least allow the tag-dependent behavior to be "added on"
in a reasonable way. But again, I agree with you -- it's too
complicated. It ends up feeling like "renderTag=null turns on tag-
dependent behavior", not to mention the whole tertiary logic issue.
Maybe I wasn't entirely clear initially -- I want to replace the
renderTag parameter with tag-dependent rendering, and un-deprecate
the element parameter to handle the edge cases.
I understand the mantra of doing everything to type the minimum,
but I am not a groupie of it. I believe its all about simplicity,
and simplicity does not mean always - do everything to reduce the
code to minimum.
Sure, inflexibly sticking to any mantra usually ends up badly. I'll
take simple over smart any day if smart=overly complicated.
This is as much about "Do What I Mean" as it is about reducing
typing. I think renderTag with a hard-coded default of true (Jesse's
original implementation) was an attempt to DWIM by always rendering
tags, but that didn't turn out to be much better than the old
behavior (i.e. *not* rendering by default).
So, at the risk of repeating myself, a central question here is: how
often would tag-dependent rendering actually do what the user means?
If it's not likely to be at least 80%, it's not worth doing. If it's
almost always correct, it's certainly more useful than the renderTag
parameter.
-Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
