>>> 3455 >> >> Does not need to be merged. >> I don't think it should have been made public in the first place. The >> real solution is to refactor toString, but obviously not everyone >> thinks this. > > Someone else will need to speak to this. I'm not sure what the object > of this code is. > > Will this prevent toString from being refactored? Is this a suitable > temporary solution to the problem in lieu of refactored toString code? > Can you provide the toString code instead?
Meller and I disagreed on this. I prefer to keep it protected. He wanted it public so we didn't have to reroll the loop toString. If we open it public now, then we will have unnecessary API changes down the road if we move it back to protected. (I'm sure he thinks that we should just always leave it public, but I think APIs should be minimal.) In any case, it doesn't actually fix a release bug. IMO, it shouldn't go into 0.6.x. Nor should the debate hold up 0.6.1. >>> 3479 >> >> Is a feature addition. Doesn't belong in 0.6.1, IMO (I could be >> wrong; >> if so, please point me at the "what can go in point releases" >> document). > > This is a kind of feature addition, but I think it is a satisfactory > solution for what is clearly a bug, whereas any other solution would > be > new and likely not as complete as this solution which we already have. > I think including this is fair, please do disagree if you feel > otherwise. That's a fair point. I don't want to get into a situation where we're squeezing in last-minute features, but if it solves a clear bug, then I have no objection. S --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
