On 2011-06-25 18:29, Walter Bright wrote: > On 6/25/2011 5:31 PM, Jonathan M Davis wrote: > > So, while the majority have indicated in the past renaming functions in > > Phobos to be properly camelcased is worth breaking code in the general > > case, there is no such consensus in this particular case, so toStringz > > is sticking around. > > There's a large community using D that doesn't necessarily participate in > ng discussions. I'd like to see more than a simple majority in order to > rename existing functions (especially ones that have been around a while). > > Breaking existing code really, really annoys people. It drives people away > from using D as "unstable" - and they'd be right. > > I don't think we can create a viable D community if we break existing code > every month without really, really good reasons to.
The vote to rename std.string's functions to be properly camelcased was virtually unanimous. It wasn't a simple majority. True, that's not the entirety of D users out there, but the feelings on this group appear to be fairly strong that they want Phobos to be consistent in its function naming. And if this group feels that way, then odds are that a fair portion of the rest of the D community feels the same way. So, I think that it's worth fixing the names - especially if we do it sooner than later. That done, as long as we ensure that new code follows the proper naming conventions, then in the long run, such changes won't be necessary anymore. If the community here was more wishy-washy about such changes (as they were with toStringz), then no, it wouldn't be worth making the change. But it's clear that almost everyone on this list wants the functions in Phobos to be properly camelcased so that their naming is consistent with Phobos' naming conventions. So, changes along those lines are being made where it makes sense. Beyond that, I don't think that we're doing much in the way of function renaming. Certainly, I don't intend to go and rename a bunch of functions just because I don't quite like the names. I'm fixing those which are not properly camelcased, because it's quite clear that almost everyone here wants that to be done. And all such functions are being appropriately deprecated, so code shouldn't be breaking right out from under people. And once those functions are fixed, it shouldn't be an issue anymore. The problem is that over Phobos' history, it hasn't been consistent in naming things, which causes problems for people trying to use it - especially newbies. In the long run, it'll be easier to use Phobos (and will reflect better on the library) if its functions consistently follow the same naming conventions. So, in general, I agree with you about avoiding breaking code, but in this particular case, I think that it's pretty clear that it's worth it. - Jonathan M Davis
