I tried format document but that just prettifies the code, is there a tool to reorder the appearance of the namespaces, classes, their properties in a file ( lexicographical or otherwise ) so that two autogenerated files can be textually compared to each other?
Human generated files don't have more than a class in a file, or they are hierarchical when there are many classes in the same file, so no need to resort the order of classes and their properties, but is there a tool to reformat and order a file by Class names, fields, properties, Method names and signatures?
The original problem is with updating WCF service, moves classes all over the Reference.cs file.
Edit :
To reproduce just update a WCF service and watch the Reference.cs file being completely juxtaposed, classes move up and down in the file. Trying to have a large autogenerated C# file sorted in unique way to enable textual comparison while the structure remains isomorphic to the original code.
Edit 2: Concrete example code
Suppose file is as below (psudo code)
Namespace S2
{
Class C2
Method M2
Property P2
Constructor CTOR2
Field F2
Method M1
Property P1
Field F1
Constructor CTOR1
}
Namespace S1
{
Class C1
Method M2
Property P2
Constructor CTOR2
Field F2
Method M1
Property P1
Field F1
Constructor CTOR1
}
then after sorted formatting it would be
Namespace S1
{
Class C1
Constructor CTOR1
Constructor CTOR2
Field F1
Field F2
Property P1
Property P2
Method M1
Method M2
}
Namespace S2
{
Class C2
Constructor CTOR1
Constructor CTOR2
Field F1
Field F2
Property P1
Property P2
Method M1
Method M2
}
Note : it doesnt matter what the order of properties, methods, fields are apearing, as long as after the sort they always apear in the same order.
is there a tool to reorder the appearance of the namespaces, classes,
their properties in a file ( lexicographical or otherwise ) so that
two autogenerated files can be textually compared to each other?
After spending a long time serching it, I found these:
1) Resharper extension and its Greenkeeper has stated this.
2) CodeMaid extension
But l am not sure whether these extensions meet all your requirements and if that still is not what you're looking for, I'm afraid what you want is not supported so far.
I recommend you could post a feature request in our User Voice forum(DC)----suggest a feature to share your idea.
Besides, you could share the link in this thread and anyone who is interested in this including us will vote it to get the attention of Microsoft as soon as possible.
Hope it could help you.
Related
Consider code below:
mixin M {}
abstract class I {}
class A = I with M;
class B = I with M;
void main() {
final A? a = A();
final B? b = B();
final I? i1 = a ?? b; // compilation error saying "A value of type 'Object?' can't be assigned to a variable of type 'I?'"
}
Could you please help me to understand why I am having compilation error using "??" operator.
Dart 2.19.0
The a ?? b expression needs to figure out a single type which represents the two possible resulting values, one of type A or one of type B?.
Rather than checking that both A and B? are assignable to I?, it tries to figure out the type of the result of a ?? b as a single type combining both A and B?, which means finding a supertype of both A and B.
To do that, it computes an upper bound using the language-specified "least upper bound" algorithm. (I quote the name, because it finds an upper bound, which is sometimes a least upper bound, but not always.)
The two types are:
A with immediate supertypes I and M, both of which have immediate supertype Object, which has supertype Object? (and all other top types).
B? with supertypes I?, M? and their supertype Object?.
The problem here is that while it can see that I and I? occur in those types, and it can therefore decide that I? is an upper bound,
it also finds M and M? and decides that M? is an upper bound,
and those two types are otherwise completely equivalent, they have the same length of the super-class chain up to Object and are not related to each other. Neither is a least upper bound. So the algorithm ignores them and look for something that's both shared and does not have another type of equal "depth from Object". And it finds Object?.
Which is not assignable to I.
This is a known shortcoming (among several) of the least upper bound algorithm in Dart, but it's a hard problem to solve optimally, because it's very, very easy for a class to introduce some internal private superclass, and sometimes that type then becomes the least upper bound of two public subclasses, leaving users scratching their head.
There are requests to do better, for example by not ignoring the context type, but changing the type inference has to be done very carefully. It can break existing code which has been fine-tuned to the current behavior.
There are no great workarounds here, but there are functional ones.
You will have to rewrite the code to ensure that the static type of the two branches do not both have the unnecessary M type in them.
Rather than down-casting the result to I? at the end, which requires a runtime type check, I'd up-cast the original values:
final I? i3 = a ?? (b as I?); // ignore: unnecessary_cast
That should be completely free up-casts, but may (will!) cause analyzer warnings that you'll have to ignore.
Compiler doesn't seem to recognise that objects a and b are of classes inherited of I in that case.
So the syntax does the same, but in the first case needs help with casting.
final I? i1 = (a ?? b) as I?;
This does not give an error.
I have written several helper functions in F# that enable me to deal with the dynamic nature of Excel over the COM/PIA interface. However when I go to use these functions in an Excel-DNA UDF they do not work as expected as Excel-DNA is pre-processing the values in the array from excel.
e.g. null is turned into ExcelDna.Integration.ExcelEmpty
This interferes with my own validation code that was anticipating a null. I am able to work around this by adding an additional case to my pattern matching:
let (|XlEmpty|_|) (x: obj) =
match x with
| null -> Some XlEmpty
| :? ExcelDna.Integration.ExcelEmpty -> Some XlEmpty
| _ -> None
However it feels like a waste to convert and then convert again. Is there a way to tell Excel-DNA not to do additional processing of the range values in a UDF and supply them equivalent to the COM/PIA interface? i.e. Range.Value XlRangeValueDataType.xlRangeValueDefault
EDIT:
I declare my arguments as obj like this:
[<ExcelFunction(Description = "Validates a Test Table Row")>]
let isTestRow (headings: obj) (row: obj) =
let validator = TestTable.validator
let headingsList = TestTable.testHeadings
validateRow validator headingsList headings row
I have done some more digging and #Jim Foye's suggested question also confirms this. For UDF's, Excel-DNA works over the C API rather than COM and therefore has to do its own marshaling. The possible values are shown in this file:
https://github.com/Excel-DNA/ExcelDna/blob/2aa1bd9afaf76084c1d59e2330584edddb888eb1/Distribution/Reference.txt
The reason to use ExcelEmpty (the user supplied an empty cell) is that for a UDF, the argument can also be ExcelMissing (the user supplied no argument) which might both be reasonably null and there is a need to disambiguate.
I will adjust my pattern matching to be compatible with both the COM marshaling and the ExcelDNA marshaling.
I'm currently having a problem with dealing with linking between two modules with different baselines.
Example:
I have a module A with 10 baselines and module B with 10 baselines.
Links are out links from A => B. The last baseline of module A has been done 1 month after the last baseline of module B. In the meantime more objects in module B have been created and were linked from module A to them.
So now I have some links in the last baseline of module A that link to objects in module B that are non existent in the last baseline of module B (only are existent in the last baseline++).
When I run my DXL-Script in order to get all linked objects I also get the IDs of these non existent object eventhough they do not exist in the last baseline. I open both modules and load the last baseline with the load(module, baseline,false) function. The name of the baseline works and my debugging shows me that I'm really working on the latest baseline. But somehow these non existent objects are listed because of the linking. I've read something about echoed links but they do not work for me.
A possible solution would be to get the Date of the baseline of module A and compare it with the creation date of the linked object. But there must be an easier and cleaner way imho... any ideas?
I am sorry that I do not have a direct answer to your question. I tried a script between two modules (A and B) like you presented. I linked the objects, made a new baseline, and added a few more objects that was also linked up.
I do not meet the problem you presented when I run the following script. I hope there could be something that gives you a new idea. Basically I open a baseline of Module B and count in-links. Newer objects (which I find in current version) are not included in this count.
Module modB = read("/Testmappe/ModuleB", false)
Module baselineModuleB
Object objB
Link l
string linkModName = "*"
int countLinks = 0
// baseline(MAJ, MIN, SUFFIX)
Baseline myBaseline = baseline(0, 1, "")
if(baselineExists(modB, myBaseline))
{
baselineModuleB = load(modB, myBaseline, false)
for objB in baselineModuleB Module do {
for l in all(objB<-linkModName) do {
countLinks++
}
}
print "Number of in-links are: " countLinks ""
}
F# has feature called "Type extension" that gives a developer ability to extend existing types.
There is two types of extensions: intrinsic extension and optional extension. First one is similar to partial types in C# and second one is something similar to method extension (but more powerful).
To use intrinsic extension we should put two declarations into the same file. In this case compiler will merge two definitions into one final type (i.e. this is two "parts" of one type).
The issue is that those two types has different access rules for different members and values:
// SampleType.fs
// "Main" declaration
type SampleType(a: int) =
let f1 = 42
let func() = 42
[<DefaultValue>]
val mutable f2: int
member private x.f3 = 42
static member private f4 = 42
member private this.someMethod() =
// "Main" declaration has access to all values (a, f1 and func())
// as well as to all members (f2, f3, f4)
printf "a: %d, f1: %d, f2: %d, f3: %d, f4: %d, func(): %d"
a f1 this.f2 this.f3 SampleType.f4 (func())
// "Partial" declaration
type SampleType with
member private this.anotherMethod() =
// But "partial" declaration has no access to values (a, f1 and func())
// and following two lines won't compile
//printf "a: %d" a
//printf "f1: %d" f1
//printf "func(): %d" (func())
// But has access to private members (f2, f3 and f4)
printf "f2: %d, f3: %d, f4: %d"
this.f2 this.f3 SampleType.f4
I read F# specification but didn't find any ideas why F# compiler differentiate between value and member declarations.
In 8.6.1.3 section of F# spec said that "The functions and values defined by instance definitions are lexically scoped (and thus implicitly private) to the object being defined.". Partial declaration has all access to all private members (static and instance). My guess is that by "lexical scope" specification authors specifically mean only "main" declaration but this behavior seems weird to me.
The question is: is this behavior intentional and what rationale behind it?
This is a great question! As you pointed out, the specification says that "local values are lexically scoped to the object being defined", but looking at the F# specification, it does not actually define what lexical scoping means in this case.
As your sample shows, the current behavior is that the lexical scope of object definition is just the primary type definition (excluding intrinsic extensions). I'm not too surprised by that, but I see that the other interpretation would make sense too...
I think a good reason for this is that the two kinds of extensions should behave the same (as much as possible) and you should be able to refactor your code from using one to using the other as you need. The two kinds only differ in how they are compiled under the cover. This property would be broken if one kind allowed access to lexical scope while the other did not (because, extension members technically cannot do that).
That said, I think this could be (at least) clarified in the specification. The best way to report this is to send email to fsbugs at microsoft dot com.
I sent this question to fsbugs at microsoft dot com and got following answer from Don Syme:
Hi Sergey,
Yes, the behaviour is intentional. When you use “let” in the class scope the identifier has lexical scope over the type definition. The value may not even be placed in a field – for example if a value is not captured by any methods then it becomes local to the constructor. This analysis is done locally to the class.
I understand that you expect the feature to work like partial classes in C#. However it just doesn’t work that way.
I think term "lexical scope" should be define more clearly in the spec, because otherwise current behavior would be surprising for other developers as well.
Many thanks to Don for his response!
So, by a hilarious series of events, I downloaded the FParsec source and tried to build it. Unfortunately, it's not compatible with the new 1.9.9.9. I fixed the easy problems, but there are a couple of discriminated unions that still don't work.
Specifically, Don Syme's post explains that discriminated unions containing items of type obj or -> don't automatically get equality or comparison constraints, since objects don't support comparison and functions don't support equality either. (It's not clear whether the automatically generated equality/comparison was buggy before, but the code won't even compile now that they're no longer generated.)
Here are some examples of the problematic DUs:
type PrecedenceParserOp<'a,'u'> =
| PrefixOp of string * Parser<unit,'u> * int * bool * ('a -> 'a)
| others ...
type ErrorMessage =
| ...
| OtherError of obj
| ...
Here are the offending uses:
member t.RemoveOperator (op: PrecedenceParserOp<'a, 'u>) =
// some code ...
if top.OriginalOp <> op then false // requires equality constraint
// etc etc ...
or, for the comparison constraint
let rec printMessages (pos: Pos) (msgs: ErrorMessage list) ind =
// other code ...
for msg in Set.ofList msgs do // iterate over ordered unique messages
// etc etc ...
As far I can tell, Don's solution of tagging each instance with a unique int is the Right Way to implement a custom equality/comparison constraint (or a maybe a unique int tuple so that individual branches of the DU can be ordered). But this is inconvenient for the user of the DU. Now, construction of the DU requires calling a function to get the next stamp.
Is there some way to hide the tag-getting and present the same constructors to users of the library? That is, to change the implementation without changing the interface? This is especially important because it appears (from what I understand of the code) that PrecedenceParserOp is a public type.
What source did you download for FParsec? I grabbed the latest from the FParsec BitBucket repository, and I didn't have to make any changes at all to the FParsec source to get it to compile in VS 2010 RC.
Edit: I take that back. I did get build errors from the InterpLexYacc and InterpFParsec sample projects, but the core FParsec and FParsecCS projects build just fine.
One thing you could do is add [<CustomEquality>] and [<CustomComparison>] attributes and define your own .Equals override and IComparable implementation. Of course, this would require you to handle the obj and _ -> _ components yourself in an appropriate way, which may or may not be possible. If you can control what's being passed into the OtherError constructor, you ought to be able to make this work for the ErrorMessage type by downcasting the obj to a type which is itself structurally comparable. However, the PrecendenceParserOp case is a bit trickier - you might be able to get by with using reference equality on the function components as long as you don't need comparison as well.