I have a procedural macro that generates an enum plus its variants and I'd like to add configurable visibility to it, but it looks like the syn::Variant struct doesn't have a visibility field. For some reason it can parse a variant with a visibility so I'm not sure if there's another mechanism for me to set the visibility that I've missed.
Is there another way to set the visibility, or is this a bug?
Unfortunately, this is by design.
https://doc.rust-lang.org/reference/items/enumerations.html#variant-visibility says: "Enum variants syntactically allow a Visibility annotation, but this is rejected when the enum is validated. This allows items to be parsed with a unified syntax across different contexts where they are used."
Also, syn ignores the visibility when parsing an enum variant: https://github.com/dtolnay/syn/blob/bf7774b10555bd24a14008ad0c46d6ebde202a1c/src/data.rs#LL166C28-L166C28
Related
I have a requirement to display a drop down menu for a String type in Hybris Management Console, restricting the value to some specific values.
As suggested in several forums, I tried to create this entry as an enumeration type but characters like '-' are to be allowed in the enumeration values, as this column receives some specific values which comprise of '-'.
How do I solve this issue?
The people advising you probably didn't understand your requirements. As such, an enumeration type is clearly not appropriate in this case. Consider the alternatives. Is there a Map Type available? What other type might allow you to achieve your goal?
Actually, you could use the hybris Enumeration. In hybris Enum Types have a code and a name. The code is the unique representation for this enum and cannot contain a "-". The name however is a localized representation of that value and can include every character your database is able to store. Have a look here:
https://help.hybris.com/6.5.0/hcd/8c895989866910148d6a802f06651702.html
Additionally, hybris enables you to dynamically create new enumeration values, which is kind of nice.
I have an enum.
enum Status {A,B,C}
Is it possible to add another status using meta programming?
Java enums are a syntactic sugar over some boilerplate code, with static atributes and some helper methods (like values()). Enums feature private constructors, and Groovy doesn't allow calling new on an enum. So it gets kinda hacky trying to workaround this.
No. Either you have enum (which is always a fixed set of choices) or you have a dynamic set of choices (which isn't an enum).
Use a Set instead.
I am learning about the .NET assembly version number. While looking for when to change assembly version number, I came across the term breaking change. I believe "breaking change" is a vast area, and I know few possiblities of breaking changes:
Interface changed
Exposed method changed
Please help me to identify any other possiblities that can be considered breaking changes.
I don't know if I can give an exhaustive list, but whenever you change the semantics or functionality of a visible type or type member (like method, constructor, property, event, and so on), that will be a breaking change.
A type or member is "visible" outside your assembly if it is public or protected (including protected internal), and all containing types (classes and structs that this program element "sits" inside) are also public or protected.
Also, if you change the "formal" appearance of a member, like changing a field into a property, or changing the (return) type of a method, property, event, and so on, or changing the signature of a method, including changing optional parameters or their default values. Adding a new overload to an existing method could in some cases be a breaking change, like if a call by the consuming code could possibly become ambiguous.
Changing in any way the "fields" (named constants) of an enum, whether renaming or changing the order, is a breaking change, like changing the value of a const field.
According to .NET and Compatibility: Breaking Changes in a Managed World (Kit George), there was once a document from Microsoft "defining" this term. Don't know if it is still out there, or if it is useful.
As I understand, when using automated properties, one must write both set and get methods.
However, when I look at Microsoft's System.Exception, there are some properties that clearly does not follow this demand, for instance: http://msdn.microsoft.com/en-us/library/system.exception.innerexception.aspx.
Can someone please explain me how can this be?
When using an automatic property, one never writes set and get methods. The compiler provides both for you.
If you see a property without a set, or without a get, it was defined the long way, and not an automatic property.
The fact that the backing property is a legal C# name, and not a compiler-reserved name, is another clue that you're looking at a manual property. So is the fact that this property has been around since long before automatic properties were implemented.
Sorry?
What about "no public set"?
Can be.... protected or private and thus be filtered in the documentation.
This question is similar, but my question seems to get asked in an unanswered comment.
I create a C# class. I use alt-insert to add a constructor. I add an argument to the constructor, and then I use alt-enter to create and initialize a field from that argument, like so:
The problem is that my field gets created as a readonly field, and in many cases I do not want to create a readonly field.
readonly int my_int;
How can I tell ReSharper not to add make my field readonly? I've tried to do a pretty thorough search in the ReSharper options, but apparently I'm missing something!
I too cannot find any option to change the creation default; however, if you allow R# to create this field as it likes (ie readonly), and later type this:
public void Bar(int baz)
{
my_int = baz;
}
then the assignment to my_int will get a red squiggly underline, since it is illegal, and the offered quick fix (Alt+Enter) at that location will be Make field 'my_int' non-readonly.
So in the spirit of 'code first', you might want to just let R# do its thing, and also use it to change it as and when you actually need it changed (which might of course turn out to be never...)
The field creation is hardcoded to be readonly on creation. The idea is that you're creating a field, so it doesn't have any usages to default to the most restrictive, if you try to write to it elsewhere, you can alt+enter at that point and remove the readonly status. If the field already exists, ReSharper will try and initialise the existing field from the parameter.
If you want to, you can write a plugin to generate the field as non-readonly. You should look at the IntroduceFieldFix class in dotPeek. It's got several constructors, which binds the quick fix to the warning squigglies, and it will introduce a field using the default pattern for the current language (which is hardcoded to "private readonly $0 $1;")
You can create a class that also derives from InitializeFieldFix, and includes a constructor that takes UnusedParameterWarningBase as a parameter. You can then follow the same implementation as IntroduceFieldFix, but provide a different pattern for the field creation, checking for the current language first.
Another option may be to use 'Introduce Field' refactoring instead. The best way to call it is to use 'Refactor This' (Ctrl+Shift+R) on a parameter declaration and choose 'Introduce Field' from the reduced number of refactoring options. By default it will generate writable field but there is also an option to change modifiers.