September 06, 2011 [dmd-beta] Migration path for enum Endian? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 9/6/11 4:52 PM, Jonathan M Davis wrote: > On Tuesday, September 06, 2011 17:03:30 Nick Sabalausky wrote: >> The names inside std.system.Endian were changed from UpperCamelCase to lowerCamelCase, which makes sense, but maybe the old names should still exist for migration? > > Yu can't rename enum values without breaking code. Any final switches would be broken if you left in the old values as would anything using std.traits.EnumMembers. I think EnumMembers is used rarely enough to not warrant much worry. If final switch fails to compile because it doesn't handle all aliases of the same value, that's a bug in the compiler. So I think keeping old values alongside new ones is good practice. > A simple renaming is caught and pointed out quite well > by the compiler's spellchecker. Code breakage is what it is. Andrei |
September 07, 2011 [dmd-beta] Migration path for enum Endian? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 9/7/11, Andrei Alexandrescu <andrei at erdani.com> wrote: > I think EnumMembers is used rarely enough to not warrant much worry. O.T. but EnumMembers is great for testing purposes. I've recently used it to test various drawing methods which are selected at compile-time via an enum argument, snippet below: foreach (index, method; EnumMembers!RoundMethod) { roundedRectangle!(method)(ctx, index * xPos, 0, 100, 100, 10, 10); ctx.fill(); } results: http://i.imgur.com/hTuGl.png |
September 06, 2011 [dmd-beta] Migration path for enum Endian? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Tuesday, September 06, 2011 17:01:28 Andrei Alexandrescu wrote: > On 9/6/11 4:52 PM, Jonathan M Davis wrote: > > On Tuesday, September 06, 2011 17:03:30 Nick Sabalausky wrote: > >> The names inside std.system.Endian were changed from UpperCamelCase to > >> lowerCamelCase, which makes sense, but maybe the old names should > >> still > >> exist for migration? > > > > Yu can't rename enum values without breaking code. Any final switches would be broken if you left in the old values as would anything using std.traits.EnumMembers. > > I think EnumMembers is used rarely enough to not warrant much worry. If final switch fails to compile because it doesn't handle all aliases of the same value, that's a bug in the compiler. So I think keeping old values alongside new ones is good practice. I don't know how rare EnumMembers usage is, but it's definitely used. I use it in unit tests and the like. It's probably not a big issue for std.system.Endian though. Regardless, it was discussed in the pull request. I said that I hadn't provided duplicate enum values with the old names, and you merged it in that way. > > A simple renaming is caught and pointed out quite well > > by the compiler's spellchecker. > > Code breakage is what it is. True. But this is easy-to-fix code breakage. My point is that you _can't_ avoid code breakage when renaming enums. It's just a question of what code you're going to break, how easy such breakage is going to fix, and how common it is. Renamings are going to be more common but very easy to fix. Something like EnumMembers may be less common, but it's going to be more subtle when it breaks, and the code which uses it would have to be changed to explicitly ignore duplicate enum values, which could be problematic. - Jonathan M Davis |
September 06, 2011 [dmd-beta] Migration path for enum Endian? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 9/6/11 5:16 PM, Jonathan M Davis wrote: > On Tuesday, September 06, 2011 17:01:28 Andrei Alexandrescu wrote: >> On 9/6/11 4:52 PM, Jonathan M Davis wrote: >>> On Tuesday, September 06, 2011 17:03:30 Nick Sabalausky wrote: >>>> The names inside std.system.Endian were changed from UpperCamelCase to >>>> lowerCamelCase, which makes sense, but maybe the old names should >>>> still >>>> exist for migration? >>> >>> Yu can't rename enum values without breaking code. Any final switches would be broken if you left in the old values as would anything using std.traits.EnumMembers. >> >> I think EnumMembers is used rarely enough to not warrant much worry. If final switch fails to compile because it doesn't handle all aliases of the same value, that's a bug in the compiler. So I think keeping old values alongside new ones is good practice. > > I don't know how rare EnumMembers usage is, but it's definitely used. I use it in unit tests and the like. It's probably not a big issue for std.system.Endian though. Regardless, it was discussed in the pull request. I said that I hadn't provided duplicate enum values with the old names, and you merged it in that way. Doesn't mean we're sworn into that, and now that the problem was raised by a second person, I thought I'd put it back on the plate. >>> A simple renaming is caught and pointed out quite well >>> by the compiler's spellchecker. >> >> Code breakage is what it is. > > True. But this is easy-to-fix code breakage. My point is that you _can't_ avoid code breakage when renaming enums. It's just a question of what code you're going to break, how easy such breakage is going to fix, and how common it is. Renamings are going to be more common but very easy to fix. Something like EnumMembers may be less common, but it's going to be more subtle when it breaks, and the code which uses it would have to be changed to explicitly ignore duplicate enum values, which could be problematic. I don't quite buy into this all. Anyway, perhaps an EnumDistinctMembers abstraction would be the best outcome of this discussion. Andrei |
September 06, 2011 [dmd-beta] Migration path for enum Endian? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Tuesday, September 06, 2011 17:24:42 Andrei Alexandrescu wrote: > On 9/6/11 5:16 PM, Jonathan M Davis wrote: > > On Tuesday, September 06, 2011 17:01:28 Andrei Alexandrescu wrote: > >> On 9/6/11 4:52 PM, Jonathan M Davis wrote: > >>> On Tuesday, September 06, 2011 17:03:30 Nick Sabalausky wrote: > >>>> The names inside std.system.Endian were changed from > >>>> UpperCamelCase to > >>>> lowerCamelCase, which makes sense, but maybe the old names should > >>>> still > >>>> exist for migration? > >>> > >>> Yu can't rename enum values without breaking code. Any final > >>> switches > >>> would be broken if you left in the old values as would anything > >>> using > >>> std.traits.EnumMembers. > >> > >> I think EnumMembers is used rarely enough to not warrant much worry. > >> If > >> final switch fails to compile because it doesn't handle all aliases of > >> the same value, that's a bug in the compiler. So I think keeping old > >> values alongside new ones is good practice. > > > > I don't know how rare EnumMembers usage is, but it's definitely used. I use it in unit tests and the like. It's probably not a big issue for std.system.Endian though. Regardless, it was discussed in the pull request. I said that I hadn't provided duplicate enum values with the old names, and you merged it in that way. > > Doesn't mean we're sworn into that, and now that the problem was raised by a second person, I thought I'd put it back on the plate. I'm just saying that it was discussed before and that you were involved in it. If we want to revisit it, we can. > >>> A simple renaming is caught and pointed out quite well > >>> by the compiler's spellchecker. > >> > >> Code breakage is what it is. > > > > True. But this is easy-to-fix code breakage. My point is that you _can't_ avoid code breakage when renaming enums. It's just a question of what code you're going to break, how easy such breakage is going to fix, and how common it is. Renamings are going to be more common but very easy to fix. Something like EnumMembers may be less common, but it's going to be more subtle when it breaks, and the code which uses it would have to be changed to explicitly ignore duplicate enum values, which could be problematic. > > I don't quite buy into this all. Anyway, perhaps an EnumDistinctMembers abstraction would be the best outcome of this discussion. That may very well be a good idea. I'm just saying that there _will_ be code breakage from changing enum values pretty much no matter what you do. It's just a question of the nature of the breakage and what the pros and cons of going with one type of breakage over another are. - Jonathan M Davis |
September 06, 2011 [dmd-beta] Migration path for enum Endian? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | Also, I would point out that because you can't deprecate enum values, the only deprecation path is to have to have soft migration followed by removal. So, I don't know how much code breakage you're really saving by leaving the old enum values in temporarily. We can still do it, but the deprecated keyword and whatever it brings to the table can't be involved in the process, because you can't put attributes on enum values. Fortunately, there weren't all that many enum values in Phobos which didn't follow the correct naming conventions outside of std.socket, and after this release, the only enum values with incorrect names should be the ones in std.socket, which looks like it's probably going to be revamped anyway. - Jonathan M Davis |
September 06, 2011 [dmd-beta] Migration path for enum Endian? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | Probably a good idea would be to enhance the language to allow "deprecated" in front of single enum values:
enum Test
{
a,
deprecated b,
c
}
At this point we should pay a great deal of attention to this language feature.
Andrei
On 9/6/11 5:39 PM, Jonathan M Davis wrote:
> Also, I would point out that because you can't deprecate enum values, the only deprecation path is to have to have soft migration followed by removal. So, I don't know how much code breakage you're really saving by leaving the old enum values in temporarily. We can still do it, but the deprecated keyword and whatever it brings to the table can't be involved in the process, because you can't put attributes on enum values.
>
> Fortunately, there weren't all that many enum values in Phobos which didn't follow the correct naming conventions outside of std.socket, and after this release, the only enum values with incorrect names should be the ones in std.socket, which looks like it's probably going to be revamped anyway.
>
> - Jonathan M Davis
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
|
September 06, 2011 [dmd-beta] Migration path for enum Endian? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Tuesday, September 06, 2011 17:44:04 Andrei Alexandrescu wrote: > Probably a good idea would be to enhance the language to allow "deprecated" in front of single enum values: > > enum Test > { > a, > deprecated b, > c > } > > At this point we should pay a great deal of attention to this language feature. It sounds like a good improvement to me. deprecated does need a bit of an overhaul (as discussed in https://github.com/D-Programming- Language/dmd/pull/345 ). I believe that you said in another post recently that you had some good ideas about that, and I look forward to you posting them. - Jonathan M Davis |
September 06, 2011 [dmd-beta] rdmd is old, wasn't rebuillt | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky |
On 9/6/2011 2:23 PM, Nick Sabalausky wrote:
> The RDMD included in the beta hasn't been rebuilt from latest HEAD. It's still old and is missing some critical bugfixes that are already in HEAD.
>
On which platform?
|
September 07, 2011 [dmd-beta] new dmd 1.070 and 2.055 beta | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | I was talking specifically about changelog.dd in the DMD repo [1], which does not have entries for 2.054 and the soon-to-be 2.055, whereas the files in the druntime and Phobos root directories at least seem to be up to date. You seem to be updating the file in the d-p-l.org repo directly ? which one should be used in the future? David [1] https://github.com/D-Programming-Language/dmd/blob/3da0a36698/changelog.dd On 9/6/11 8:23 AM, Walter Bright wrote: > There's a whole section on 2.054 - what is missing? > > On 9/5/2011 8:03 PM, David Nadlinger wrote: >> On 9/6/11 1:52 AM, Walter Bright wrote: >>> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip >> >> Sorry for being a bit on the slow side, but again a question concerning the changelogs: changelog.dd in the DMD repo is missing the entries for 2.054, so the DMD changelog is kept directly in the d-p-l.org repo? Should I submit a pull request for the DMD bugs I fixed, or do you take care of compiling the list, Walter? >> >> David >> _______________________________________________ >> dmd-beta mailing list >> dmd-beta at puremagic.com >> http://lists.puremagic.com/mailman/listinfo/dmd-beta >> >> > _______________________________________________ > dmd-beta mailing list > dmd-beta at puremagic.com > http://lists.puremagic.com/mailman/listinfo/dmd-beta |
Copyright © 1999-2021 by the D Language Foundation