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.
Related
I have an non-persistent attribute (SITEID) on my WOCHANGE object that originates from the parent object, WORKORDER. For some particular reason, this attribute has a few problems that I've never really seen with other attributes before.
Based on various configurations I have tried in an attempt to remedy the issue, here are the main issues:
It doesn't trigger the WOCHANGE to save when changed.
In addition to the value not being saved, I can change the value on one record, go to another and the value persists on the different record.
The field is readonly unless I define it to have an inputmode of DEFAULT. This is odd to me, because not defining inputmode usually implies default behavior (NOT readonly).
Here are the definitions for the SITEID attribute on both the WORKORDER
and WOCHANGE objects.
SITEID also uses a TABLE domain belonging to the SITE table.
Are there any attribute rules being applied from other sources that I should be checking?
That workorder field class on there may not be desired and may be messing with things, like setting the field to read-only. Site Id is commonly a read-only field, especially when the record is no longer a new record. Because of that, the logic to make that field read-only could be buried deeper in the Maximo business logic than just that field class. You are working with a field that has a lot of special meaning in Maximo, you are likely going to stumble into many built-in business rules.
Since non-persistent fields are not saved in the database (they are in memory fields only), I don't believe they trigger the flag for a record to be saved. What would be saved? Nothing in the database (a save) is to be changed yet.
Your screenshot however shows the field as persistent. Is WOCHANGE a view? I can't recall and no longer have the resources to check.
I have a 'document' table (very original) that I need to dynamically subset at runtime so that my API consumers can't see data that isn't legal to view given some temporal constraints between the application/database. JOOQ created me a nice auto-gen Document class that represents this table.
Ideally, I'd like to create an anonymous subclass of Document that actually translates to
SELECT document.* FROM document, other_table
WHERE document.id = other_table.doc_id AND other_table.foo = 'bar'
Note that bar is dynamic at runtime hence the desire to extend it anonymously. I can extend the Document class anonymously and everything looks great to my API consumers, but I can't figure out how to actually restrict the data. accept() is final and toSQL doesn't seem to have any effect.
If this isn't possible and I need to extend CustomTable, what method do I override to provide my custom SQL? The JOOQ docs say to override accept(), but that method is marked final in TableImpl, which CustomTable extends from. This is on JOOQ 3.5.3.
Thanks,
Kyle
UPDATE
I built 3.5.4 from source after removing the "final" modifier on TableImpl.accept() and was able to do exactly what I wanted. Given that the docs imply I should be able to override accept perhaps it's just a simple matter of an erroneous final declaration.
Maybe you can implement one of the interfaces
TableLike (and delegate all methods to a JOOQ implementation instance) such as TableImpl (dynamic field using a HashMap to store the Fields?)
Implement the Field interface (and make it dynamic)
Anyway you will need to remind that there are different phases while JOOQ builds the query, binds values, executes it etc. You should probably avoid changing the "foo" Field when starting to build a query.
It's been a while since I worked with JOOQ. My team ended up building a customized JOOQ. Another (dirty) trick to hook into the JOOQ library was to use the same packages, as the protected identifier makes everything visible within the same package as well as to sub classes...
is there a default visibility in UML2 if I don't (want to) add one of the four reserved visibilities?
As I know there is + for public, - for private, # for protected and ~ for package.
Or is the default depend on the implementation language that should be used, e.g. package for Java or private for C++?
Thanks so far.
If you don't add it then it's a don't care. Languages itself have their own rules and UML does not know how a language will treat it. The same goes for tools. They place one of the symbols (either public or private) as default and you eventually can change a default to something else. But again UML does not care.
Depending on how you use it you can tell the reader that a missing symbol will mean this or that.
Edit 1: Thanks to #xmojmr digging into the UML spec and the great critic uml-diagrams.org here are two statements. OMG first (SS2.4.1):
7.3.38 Package (from Kernel)...The query makesVisible() defines whether a Package makes an element visible outside itself. Elements
with no visibility and elements with public visibility are made
visible" and "7.3.39 PackageableElement (from Kernel)...
visibility...Default value is public
and from http://www.uml-diagrams.org/property.html
Note, that there is no default visibility. Also, visibility may be suppressed from being displayed on a diagram, even if it has some value in the model (e.g. stored by UML tool). So, if visibility is not shown on a diagram, it was either not specified or suppressed
Please also note that my original statement was just an expression of my experience from using UML in the real world. Feels good to see that my experience seems to be in synch with the theories ;-)
Edit 2: Looking into the 2.5 specs I found this in chap. 7.8 Classifier Descriptions on p. 48:
Attributes
- visibility : VisibilityKind [0..1] = public
A PackageableElement must have a visibility specified if it is owned by a Namespace. The default visibility is public.
Constraints
- namespace_needs_visibility
A PackageableElement owned by a Namespace must have a visibility.
inv: visibility = null implies namespace = null
So it says the default is public. But the constraint says it must have a visibility. Which to me means that you need to specify it?
If you don't understand definition, read the definition for definition :-/
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.