It is not completely correct that with fsc.exe everything is well. If you compiler just the type definition it is true nobody complains. But if you try to compile the following
the compiler reports an error. The reason for the different behaviors of fsc.exe and fsi.exe is that the latter uses Reflection.Emit that performs additional checks on the well-formedness of the generated assembly that the fsc.exe does not perform. As a matter of fact both approaches are correct: unless you want create a type the types d1 and d are correct as witnessed by the peverify command. On the other hand it is not possible to have instances as reported by fsi.exe.
Although a warning may be reported in this case I think that the correct behavior is shown by fsc.exe since you may still have a type that cannot be instantiated but with static methods. Nevertheless in practice you must assume that if a type inherits from another type the construction of an object of the derived class must be able to initialize the portion inherited from the base class.
Antonio
type d = class new (x:int) = {} end
type d1 = class inherit d end
let v = new d1()
the compiler reports an error. The reason for the different behaviors of fsc.exe and fsi.exe is that the latter uses Reflection.Emit that performs additional checks on the well-formedness of the generated assembly that the fsc.exe does not perform. As a matter of fact both approaches are correct: unless you want create a type the types d1 and d are correct as witnessed by the peverify command. On the other hand it is not possible to have instances as reported by fsi.exe.
Although a warning may be reported in this case I think that the correct behavior is shown by fsc.exe since you may still have a type that cannot be instantiated but with static methods. Nevertheless in practice you must assume that if a type inherits from another type the construction of an object of the derived class must be able to initialize the portion inherited from the base class.
Antonio
Thank you for the kind explanation. I now understand the differences.
Best regards,
keiko
Best regards,
keiko
Topic tags
- f# × 3583
- compiler × 262
- functional × 199
- c# × 117
- classes × 96
- web × 94
- book × 83
- .net × 80
- websharper × 72
- async × 71
- server × 43
- parallel × 42
- parsing × 41
- testing × 41
- asynchronous × 29
- monad × 28
- ocaml × 26
- tutorial × 26
- haskell × 25
- workflows × 21
- html × 20
- introduction × 19
- linq × 19
- wpf × 19
- silverlight × 18
- collections × 14
- pipeline × 14
- fpish × 13
- templates × 12
- monads × 11
- opinion × 10
- plugin × 9
- reactive × 9
- scheme × 9
- solid × 9
- basics × 8
- concurrent × 8
- deployment × 8
- how-to × 8
- sitelets × 8
- complexity × 7
- python × 7
- javascript × 6
- lisp × 6
- real-world × 6
- workshop × 6
- xaml × 6
- conference × 5
- dsl × 5
- java × 5
- ml × 5
- scala × 5
- jquery × 4
- lift × 4
- metaprogramming × 4
- teaching × 4
- alt.net × 3
- aml × 3
- enhancement × 3
- formlets × 3
- reflection × 3
- compilation × 2
- computation expressions × 2
- corporate × 2
- cufp × 2
- enterprise × 2
- erlang × 2
- http × 2
- interactive × 2
- interface × 2
- iphone × 2
- iteratee × 2
- jobs × 2
- keynote × 2
- numeric × 2
- obfuscation × 2
- oop × 2
- packaging × 2
- pipelines × 2
- sockets × 2
- stm × 2
- tcp × 2
- type provider × 2
- visual studio × 2
- .net interop × 1
- abstract class × 1
- agents × 1
- agile × 1
- appcelerator × 1
- asp.net mvc 4 × 1
- asp.net web api × 1
- ast × 1
- b-tree × 1
- bistro × 1
- blog × 1
- bug × 1
- client × 1
- cloud × 1
- continuation-passing style × 1
- css × 1
- data × 1
- database × 1
- declarative × 1
- dhtmlx × 1
- documentation × 1
- dol × 1
- domain × 1
- eclipse × 1
- em algorithm × 1
- emacs × 1
- emotion × 1
- error × 1
- example × 1
- extension methods × 1
- fear × 1
- fp × 1
- functional style × 1
- gc × 1
- generic × 1
- geometry × 1
- getlastwin32error × 1
- hash × 1
- history × 1
- html5 × 1
- httpcontext × 1
- hubfs × 1
- installer × 1
- interpreter × 1
- io × 1
- ios × 1
- ipad × 1
- kendo × 1
- licensing × 1
- list × 1
- macro × 1
- macros × 1
- marshal × 1
- math × 1
- metro style × 1
- micro orm × 1
- minimum-requirements × 1
- multithreading × 1
- nancy × 1
- nested loops × 1
- object relation mapper × 1
- object-oriented × 1
- offline × 1
- option × 1
- orm × 1
- osx × 1
- pattern matching × 1
- performance × 1
- phonegap × 1
- programming × 1
- quant × 1
- range × 1
- raphael × 1
- real-time × 1
- restful × 1
- round table × 1
- runtime × 1
- rx × 1
- script × 1
- session-state × 1
- sitelet × 1
- sql × 1
- stickynotes × 1
- stress × 1
- structures × 1
- tdd × 1
- trie × 1
- type × 1
- type providers × 1
- upload × 1
- vector × 1
- visual f# × 1
- visual studio shell × 1
- windows-phone × 1
- winrt × 1
- xna × 1
![]() |
Copyright (c) 2011-2012 IntelliFactory. All rights reserved. Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Built with WebSharper |


I am now learning the interaction between inheritance and constructor calls.
But I do not understand this behavior.
type d = class new (x:int) = {} end type d1 = class inherit d endThe above code compiles with fsc.exe,
but the interactive fsi.exe raises an exception:
What is the general rule behind and why the interactive and the batch compilation disagree?
Sincerely,
keiko