In many modern OOP languages, such as Java and C#, reference types have a base class typically called Object from which all other reference types inherit their core functionality.
These languages also have a universal .toString() method shared across all the reference types, so that it's easy to extract data as a string from it.
Now here's the question: If the String class is a subclass of Object, how can Object implement a .toString() method without causing a circular dependency?
if A uses B and B implements A it's bound to cause problems, or am I totally wrong in this?
Regarding C# (and I'm pretty sure the same goes for Java), the compiler doesn't require that source files be provided in dependency order.
This means that, unlike other compilers (the F# compiler and gcc, I believe), the C# compiler allows you to refer to symbols that haven't been seen by the compiler yet (as long as both types are in the same assembly).
In other words - yes, there's is a circular dependency, but the compiler takes care of that for you. If you want to know how compilers handle circular dependencies, then that has been asked on programmers.stackexchange already.
Related
I still have to deal with Visual Basic 6.
I just found out that the correspondence of object types is enforced only at run time. See for example this question.
I was quite shocked to find this out, I always relied on type safety checks for objects.
Does somebody know if there is an architectural reason for this (that makes it at least a complex problem)?
I would understand it if there were polymorphism involved, but when the type of a parameter is a class not implemented by any other I don't see any problem in type-checking at compile-time...?
History lesson
VB versions 1 to 3 were stricter. Type consistency checks were still made at runtime, but it was stricter. If you assigned a string to an integer, you got a runtime error. I don't know why the consistency checks were only made at runtime - at a guess compile-time checks were harder to implement.
In VB version 4 the language was changed so that (for instance) assigning a string to an integer would not raise an error, but would implicitly convert the string value to an integer. For instance if the string contained "0" or "" it would be converted to 0. If the string contained, say "1E40" you would get an overflow error. Many VB programmers (including, erm, me) hated this change, and called it evil type coercion. E.g. see this article by guru Karl Peterson.
So the architectural approach was "try to convert types at runtime by guesswork, only raise an error if it's not possible". And this means, the checks have to made at runtime. I suppose in principle the compiler could detect cases where an object type is private, and not implemented by any other class, and check that at compile-time, but I guess that was not a priority for the compiler developers. It might even have been confusing for developers to understand why some assignments were checked at runtime and others at compile time.
In VB.Net the default behaviour is the same as VB6, to make it easier to upgrade legacy code. Option Strict On is preferred in VB.Net so that the checking is done at compile time. The compile-time checks are useful because they flag up mistakes early.
Only interfaces are implemented, not classes. VB6 class Car implicitly defines interface _Car that can be implemented in any external project (DLL) and can be bundled on a coclass with any other interface (incl _Boat)
When you Dim c As Car it is the interface _Car that's used by the compiler, so c can hold a reference to the _Car interface on any object, not just an instance of the Car class. E.g. you can program a coclass Mix that implements both _Car and _Boat interfaces, so Set c = New Mix compiles and runs, and so in Sail c the QI for _Boat interface actually succeeds (think the "cast" succeeds).
Note that this is not upcast nor downcast, as _Car and _Boat are not bound by any form on inheritance. But this is what COM allows you to achieve through IUnknown interface.
In modern languages they decided that you'll always require downcast explicitly in code (otherwise get a compile error), and the same with "side-casts" (as in the contrived car/boat example) as not to shoot yourself in the leg.
I have a COM component that has get_XXX and put_XXX methods inside it. I used it in a .NET project and a RCW was generated for it. I now see get_XXX and set_XXX methods and NOT the put_XXX one? Is that automatic or defined somewhere in IDL?
These are property accessor methods. A compiler that uses the COM server is expected to generate a call to get_Xxx() when the client program reads the property, put_Xxx() when it writes it. A special one that C# doesn't have at all is putref_Xxx(), used to unambiguously access an object instead of a value.
The normal translation performed by Tlbimp.exe is as a plain C# property. But that doesn't always work, C# is a lot more strict about what a property can look like:
The default property, the one that's annotated as DISPID_VALUE (dispid 0) must take a single argument to be compatible. This maps to the C# indexer property, the one that makes it look like you are indexing an array.
Any other property cannot take an argument, C# does not supported indexed properties other than the indexer.
C# does not have the equivalent of putref_Xxx(), the syntax ambiguity cannot occur in a C# program because of the previous two bullets. And the core reason that the C# team decided to put these restrictions in place, they greatly disliked ambiguity in the language.
So Tlbimp.exe is forced to deal with these restrictions, if the COM property accessors are not compatible then it must fall back to exposing them as plain methods instead of a property. With default names, they'll get the get_ and set_ prefixes. The latter one explains your question, they didn't pick put_ for an otherwise unclear reason.
Notable is that C# version 4 relaxed several of these restrictions, most of all to make interop with Office programs easier. Which was quite painful in earlier C# versions, to put it mildly. It extended the property syntax to lessen the pain, but only for COM interop. Very strongly recommended if you are still stuck on an old version of .NET, now is a good time to consider updating.
The properties themselves have to prefixes (put_ etc.), they have names, getter method, setter method, but no prefixes. Method table generated from type library receives prefixes to distinguish between getters and setters, hence the prefixes. Prefix string exactly depends on preference of the one who generates the names.
See also:
#pragma import attributes - raw_property_prefixes
By default, low-level propget, propput, and propputref methods are exposed by member functions named with prefixes of get_, put_, and putref_ respectively. These prefixes are compatible with the names used in the header files generated by MIDL.
I have a failure Marshaling a data structure (error abstract type (Custom)). There is one known abstract type in use, namely Big_int. However that Marshals fine. There is no custom C code in the application. Apart from Nums, Unix library is also used (however I don't believe there are any active objects of that type). We're Marshal'ing with Closures.
Two (only) third party libraries are in use: OCS Scheme (Scheme interpreter, pure Ocaml) and Dypgen (extensible GLR parser, also pure Ocaml). The problem is with a new feature of Dypgen, saving a dynamically extended parser.
The Ocaml error message is next to useless (it doesn't identify which abstract type with Custom tag is the culprit).
We suspected Lexbuf as the culprit because it contains a closure over an Ocaml channel, and can't be Marshal'ed, but it seems this isn't the problem. So my question is:
Which standard library components can't be Marshall'd?
Weak arrays cannot be marshaled. I am not familiar with OCS Scheme, but I would expect an interpreter for a garbage-collected language written in OCaml to use weak pointers (they let you piggy-back on OCaml's memory management).
In OCaml's defense, I do not think that the Custom method block contains the name of the type (retrospectively, that seems like a good thing to have).
EDIT: Yep:
$ grep Weak ~/Downloads/ocs-1.0.3/src/*.ml
/Users/pascal/Downloads/ocs-1.0.3/src/ocs_sym.ml:module SymTable = Weak.Make (HashSymbol)
EDIT2:
As pointed out by ygrek, there is room for a name in the custom method block. I should also clarify that weak arrays are not custom values, since my answer seemed to imply that. Weak arrays have the Abstract tag and are chained using the first word of data so that the garbage collector can traverse them in special weak-pointer-related phases of the collection cycle.
Some of my co-workers make extensive use of the VB.net concept of Modules. Unfortunately, I just don't 'get it'. I see no benefit in using modules over shared classes. Am I missing something? When would it be preferable to use a module? Or am I (as I do quite often in this language) 'just not getting it'?
In VB.net a module is a shared class. When they are compiled they are given a private constructor and methods set to shared.
There are some times when you are forced to use modules by the compiler (in the same way static classes are in C#) such as for extension methods which can not be created in side a VB.Net class.
By using modules for your helper methods you will make it easier to convert them over to extension methods later and restrict others from adding any instance methods or constructors.
That said they are a hang over from VB6 that did not support full OO programming and beyond standalone helper methods they would not widely be used.
A module is essentially the same as a shared class. The major difference is that in a module, there's no need for all the extra "shared"s, cause everything's implicitly shared. If you have no instance data and are just using the class as a kind of namespace for functions, then it's a better idea (IMO) to use a module instead and make that clear.
I am not a program designer by any means but I would really like to start getting a better grasp of how to do it and a better understanding of the .NET languages in general (VB, C#). I was reading a book by Wrox - Professional Visual Basic 2008. In it I believed it mentioned that Modules are slowly going out of existence. I can see why most coding would go into a class object but I would assume modules would always be necessary to at least keep the code clean.
Could anybody clarify this up for me? Also, I have been searching for a good source on software design but I can't seem to find any recent books published. I might be searching in the wrong places but I would really like to get my hands on one.
Thank you.
While in general they don't quite fit with OOP, they are still used and are required in some cases.
In VB.Net, if you wish to write extension methods, you are going to have to use a Module - The compiler will only allow Extension Methods to be defined in one.
You could of course get round not using Modules - an Non Inheritable Class with a private constructor and nothing but Shared Methods will achieved the same thing as a Module.
Like everything in programming (and many other things), they have their uses, and as long as they are not miss-used there is no problem with them. Right tool for the job!
The Module keyword in VB.NET primarily exists for compatibility with VB6 and earlier. Back then, most VB code was procedural with free-standing non-class Subs and Functions. The language acquired the Class keyword somewhere around VB4. Not true classes in the OOP sense, it didn't support inheritance. A feature missing from the underlying COM architecture.
It doesn't fit very well with the execution model provided by the CLR. There is no support for free functions, every method must be a member of a class. The VB.NET compiler emulates modules by declaring a class, the module procedures become Shared methods of that class. You can see this with Ildasm.exe:
.class private auto ansi sealed ConsoleApplication1.Module1
extends [mscorlib]System.Object
{
.custom instance void [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.StandardModuleAttribute::.ctor() = ( 01 00 00 00 )
} // end of class ConsoleApplication1.Module1
Note how it is private, so that code can't get a reference to it, and sealed, so that no code can derive a class from a module.
The C# compiler does the exact same thing with a "static class", the CLR doesn't have a notion of static classes either. There are plenty of good reasons for static classes, the idea of "Module" isn't obsolete. You could accomplish the same by declaring a NotInheritable Class in VB.NET code, having only Shared methods. The VB.NET compiler however doesn't enforce methods to be Shared like the C# compiler does and doesn't allow you to declare the class private. As such, a Module is just fine.
Modules are the closest thing VB has to static classes, which can be very useful, even when programming in an object-oriented environment.
And since VB has no static classes, modules are as far as I know the only way to create extension methods.
You need modules in order to define your own Extension methods