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.
Related
i am using jaxb to generate code from an xsd.
The generated code contains a lot of annotations; for classes and fields.
I am trying to use com.sun.tools.internal.xjc.Plugin to modify the generated code.
In the plugin run() method we are given an Outline class from which we can get ClassOutline. ClassOutline has an JDefinedClass final member which has the info about actual class which will be generated.
If i want to add anything, there are apis in JDefinedClass which can be used. But if i want to remove something, there is no way.
e.g. i cannot clear annotations, because the JDefinedClass.annotations() method returns an UnmodifiableCollection. so i cannot clear it or remove anything from it.
i tried to create another JDefinedClass by invoking the _class method but the ClassOutline.implClass variable is final, so i cannot set it.
how to get a JDefinedClass which does not have any annotations?
is there another phase of code generation which i can trap into to really control the generation of JDefinedClass?
The code model is, indeed mostly "write only". But, speaking of annotations, you have probably missed the methods like com.sun.codemodel.JDefinedClass.removeAnnotation(JAnnotationUse) and com.sun.codemodel.JMethod.removeAnnotation(JAnnotationUse) (implemented from com.sun.codemodel.JAnnotatable.removeAnnotation(JAnnotationUse)).
So they're there. You can remove annotations with the normal CodeModel API.
As I can see, you can also remove fields and methods from classes. So what exactly are you missing?
JDefinedClass.annotations() It return an unmodifiable collection object and you cannot modify them.
So work around for this, you can restrict annotation addition/deletion at class and field level before building JCodeModel.
You need to create a custom Jackson2Annotator class which extends Jackson2Annotator and override their methods according to your requirement.
Following are few methods which are being used for specific type of annotation property:
propertyOrder(OTB JsonPropertyOrder)
propertyInclusion(OTB JsonInclude)
propertyField(can be used for custom defined annotation at field level)
More you can discover by looking Jackson2Annotator class what fit into your need.
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.
I am developing a custom field type which should look like a MultiLookup (two Listboxes, "add" and "remove" - Buttons). But I do not want to save that data in the List that contains the field. In other words: There should be happening completely custom code.
I have an idea how to solve it, but am unsure of what type I should derive my custom control from. Or doesn't this matter when I override FieldRenderingControl and I can just use
public class MyCustomField:SPFieldText
?
It doesn't matter as long as you don't save data in the list. Choose the one with the smallest footprint, boolean or so (I don't exactly know the name).
I created a plain Groovy class (i.e Person class)with some properties. Now I want to get those declared attributes (which I've defined in my class) with their order, but I don't know how to do it.
I've tried to use Person.metaClass.getProperties() but it retrieves not only declared properties but also built-in Groovy ones.
Could you please help me on this: just get declared properties by its order when declaring.
Thank you so much!
I can't see a use case, but the compiler could reorder all fields declaration while creating bytecode. I'm pretty sure ordering is not a constraint on fields though it should mostly be the case for not modified/enhanced class
As per the JVM spec, generated fields should be marked SYNTHETIC (like generated methods) in the bytecode, so you can test with :
Person.getDeclaredFields().grep { !it.synthetic }
and filter the base Groovy fields like ClassInfo,metaClass and others beginning by __timestamp
But I'm not a specialist, there could be another way I don't think of
There was a question about this on the mailing list back in February of this year
The answer is, no. There is no way to get properties in the order they are declared in the class without doing some extra work.
You could parse the source file for the class, and generate an ordered list of property names from that
You could write a custom annotation, and annotate the fields with this annotation ie: #Order(1) String prop
You could make all of the classes where this matters implement an interface which forces them to have a method that returns the names of the properties in order.
Other than that, you probably want to have a re-think :-(
In my DSL project I have a shape with a number of decorators that are linked to properties on my domain class. But even though ieach decorator has a DisplayName property (set to a meaningfull value) it does not appear in the generated DSL project. (I have not forgtten to use regenerate the t4 files.)
Do I have to create another decorator for each property that only has the display name as a value that I wish to display or is there some other way that I can't figure out right now?
I assume by a display name for the decorator you mean you want the element in the generated DSL to appear as "Example = a_value" where a_value is the actual value and Example is the property name.
What I've done with this in the past is to create second property "ExampleDisplay" that's not browsable and is what the decorator actually points to. I then set the Kind property of the ExampleDisplay to "Calculated". You then need to provide the method that the toolkit tries to call to display the decorator which you can do a partial class.
partial class ExampleElement
{
string GetExampleDisplayValue()
{
return "Example : " + this.Example;
}
}
This is not ideal as you don't get a good way of setting the property on the DSL diagram you have to use the properties window. (There's sometime lags from the property window unless you hook into the update of the underlying property too). Getting the slick editing in the GUI that actual DSL toolkit does maybe possible but I haven't found out how.
It maybe worth ask VSX forums if you haven't already done so.