Jonathan M Davis wrote: > As was discussed in another thread, you're fairly > conservative in the D2-specific stuff that you use.
Indeed. Though I've gone into the fancy stuff, I don't go wild with it, which probably helps too. It seems the worst bugs come from combinations of new-to-D2 features more than any one individually. For example, today I decided to play with adding more javascript support to my html helpers. Properties work fine on their own. opDispatch works fine on its own. Generic templates work well. But mix them together and things that probably should work start giving errors. Nevertheless, scaling back on the ambition worked around it. I ideally wanted js.test = "hello"; js.alert(js.test); js.test = 10; To just work (that is, output a string `test = "hello"; alert(test); test = 10;` ). That didn't work, the property opDispatch and call opDispatch screwed each other over. And the property opDispatch could take a string, but not a templated argument, making it less than ideal. It wouldn't overload opDispatch()(string) with ()(int) either. Bah. I'm pretty sure all of that is supposed to work; each piece does work, if I take the others out of the class. But the thing did start working by introducing more objects to keep any individual feature from mixing too much: // the vars helper object has its own opDispatch for properties js.vars.test = "hello"; js.alert(js.vars.test); // the vars returns a Variable struct with a set helper template // so it works with more than just strings js.vars.test.set(10); That produces the correct output, but it is a more roundabout way of getting there. It keeps the features from intermingling too much and hitting unimplemented or buggy interactions. But I'm ok with it. D has always been able to do any job I throw at it one way or another.
