Comments on: API breaks can make or break a project

By: Wannabe WicketUser

Wannabe WicketUser — Sun, 08 Apr 2007 23:05:13 +0000

Hi guys,

I’m new to Wicket, and I have just read this article. I’m sorry if I misunderstood something.

I’m wondering if there is a way to keep the constructor change optional.

I imagined a simple helper/utility class, which would keep the current state of the component tree (path), a stack, basically. The implementation of this class should be a ThreadLocal variable, of course. That might be a little bit dirty for some of you, but will work.

Suppose, you have an 1.x Wicket app. In each (old style) constructor you could call this helper class twice (push/pop the tree element, at the beginning/end of the code). That makes 2 lines of code per component. That is not much tradeoff I suppose.

The Wicket API should keep the old (parentless) constructors (perhaps marked as deprecated), and they should look for the parent component from that component tree helper class.

I understand that it might require a large amount of work to keep the old API, but you could reach both goals – new features and backward compatibility.

Regards,
Gabor

By: ZedroS

ZedroS — Tue, 13 Mar 2007 07:50:27 +0000

Hum, I don’t get it properly : so at the end of the day will all the constructor change be left over and all its benefits lost ?

Or will we have them in “another way” ?

Personally, if this constructor changes is such a good stuff, I would rather like to have it. :$

And what would happen next time a ground breaking innovation is found and changing the API ? Will it be left as well ?

Just a side question : would it be possible to have this constructor change available in some kind of extension project ?

By: Eelco

Eelco — Sun, 11 Mar 2007 00:52:07 +0000

@al raichu. I think the problem with building software (and anything in life) is that you can’t have it all. The end of the day, you have to choose between tradeoffs. Now, the constructor change was something we truly believed was going to make our framework a lot better. We didn’t implement it right away, as we thought it would break too many clients etc. From a ‘management’ point of view, I believe that decision was bad; had we done it right away, we wouldn’t have had the branch problem. Otoh, had we done it, we would have ended up with the new constructor being the default, of which we now doubt it is better.

And that doubt expresses best what is going on here. There are still pros and cons for both. They seem to be more balanced now that we have actual experience with it, maybe with a slight preference to the old method. And when the the advantage isn’t that clear, we believe we really should choose for the solution that most people are working with now, and get rid of the big overhead that maintaining two branches is.

So, I don’t think the constructor change was all bad. It’s just that the gain isn’t as large as we expected, and is generally not worth maintaining a separate branch and fragmented user base for.

By: el raichu

el raichu — Fri, 09 Mar 2007 12:40:59 +0000

thank goodness! after all, an open source project is as much a social phenomenon as it is an engineering one. that’s one of the reasons why i stopped trying to learn tapestry; i’m not that bright or kickass so i couldn’t keep up back then.

there are a few times when it all boils back down to “worse is better”: simplicity, correctness, consistency, and completeness.

if the constructor change makes things more complicated, drop it.
if the constructor change makes things more inconsistent, drop it.
if the constructor change doesn’t cover more important situations as is practical than the previous design, drop it.

it’s all about framework survival, and a framework needs users to survive. if they want generics and can’t get it with wicket, they’ll go somewhere else. igor vaynberg’s code (http://papernapkin.org/pastebin/view/4900) makes me wanna go somewhere else.

By: saki

saki — Fri, 09 Mar 2007 10:58:37 +0000

Martijn,
I do not know how many projects are written in 2.0 and in production use – would be interesting to see. I personally think very few. For me the constructor change was definitely big stopper – we even did no try to use 2.0 because I can not imagin to rewrite let say 50 pages with one or more forms on each with no chance to use refactoring. Because this constructor change means you have to change every f..king component.

So I think loss of 2.0 branch will be minimal, if all goodies (models, conversions) would go to 1.x.

Hope you will end the discussion soon, so the development can continue.
Anyway thanks for great work to all wicket developers.
saki