Serialization is a known concept, widely used in Java. But how to implement it in C#? Are there interfaces used?
It is possible to use a C# serialized implementation within VB.Net and vise versa? (somewhat an independent class)?
I would appreciate a simplified example that points to valuable references. (not asking for spoon feeding)
PS: Certainly the underlying need of this question would be "What is a C# serialized implementation and how to do it"?
MSDN has a decent high-level tutorial on c# serialization here, but it sounds like you have a high-level understanding from your Java background.
Related
Background information:
I am implementing one system on two programming languages - Java and PHP. Some of the functions will be implemented on Java, and the rest of the functionalities will be implemented using PHP.
I am actually new to UML diagrams and I am not sure if I can use the same diagrams (sequence, use case, class) to explain about my system.
Apologies if I did not phrase my question in a clearer manner. This is the best I can think of.
UML diagrams are intended to be abstracted from things like the language used to implement the system; this level of abstraction is one of the reasons to use UML.
The use case diagram (reference from comments) expresses what can be done from the actor's point of view, but that's not related to the language chosen for the implementation. The language (and ways that language may help accomplish the use cases) is an implementation detail and should remain decoupled from the system features.
This question is about design / is fairly open-ended.
I'd like to use OpenCV, a large C++ library, from Haskell.
The closest solution at the moment is probably Arjun Comar's attempt to adapt the Python / Java binding generator.
See here, here, and here.
His approach generates a C interface, which is then wrapped using hsc2hs.
Due to OpenCV's lack of referential transparency in its API, as well as its frequent use of call parameters for output, for Arjun's approach to fully succeed he'll need to define a new API for OpenCV, and implement it in terms of the existing one.
So, it seems it might not be too much extra work to go whole-hog and define an API using an interface description languages (IDL), such as SWIG, protobuf-with-RPC, or Apache Thrift.
This would provide interfaces to a number of languages besides Haskell.
My questions:
Is there anything better than SWIG for a server-free solution?
(I just want to call into C++; I'd rather not go through a local server.)
If there's no good server-free solution, should I use protobuf-with-RPC or Thrift?
Related: How good is Thrift's Haskell support?
From the code, it looks like it needs updating (I see references to GHC 6).
Related: What's a good protobuf-with-RPC solution?
With Apache Thrift, you get Haskell support. You are correct, code is not generally "latest", but you rarely care. You can do complex things on other abstraction levels and keep things as simple as possible at messaging level.
Google Protobuf has no support for Haskell, nor does SWIG. With Protobuf you get C++, Java, JavaScript and Python, to my knowledge the main languages at Google. Have a look at this presentation. Without contest, Thrift and Protobuf are the best in house.
It seems in your case you have to go with Thrift, as it supports Haskell.
It sounds like the foreign function interface for C++ is what you want:
Hackage,
Github
Disclaimer: I haven't used it, only heard good things about it.
Googled a little bit, but still not sure whether there is some standard library in Haskell dealing with inter-process communication stuff, since I am new to Haskell, I also hope that the library is well documented, better some small example (e.g. passing some data types and use them)....
Many commercial and open source IPCs have Haskell bindings:
0MQ
Thirft
Messagepack
I have made the best experiences with Messagepack because it is quite light weight.
I've created a simple library to solve the most basic aspects of this problem: http://hackage.haskell.org/package/ipcvar
I'm writing my master thesis, which deals with AOP in .NET, among other things, and I mention the lack of support for replacing classes at load time as an important factor in the fact that there are currently no .NET AOP frameworks that perform true dynamic weaving -- not without imposing the requirement that woven classes must extend ContextBoundObject or MarshalByRefObject or expose all their semantics on an interface.
You can however do this with Java in the JVM thanks to ClassFileTransformer:
You extend ClassFileTransformer.
You subscribe to the class load event.
On class load, you rewrite the class and replace it.
All this is very well, but my project director has asked me, quite in the last minute, to give him a list of frameworks (and associated languages) that do / do not support class replacement. I really have no time to look for this now: I wouldn't feel comfortable just doing a superficial research and potentially putting erroneous information in my thesis.
So I ask you, oh almighty programming community, can you help out? Of course, I'm not asking you to research this yourselves. Simply, if you know for sure that a particular framework supports / doesn't support this, leave it as an answer. If you're not sure please don't forget to point it out.
Thanks so much!
EDIT: #ewernli
I'm asking about (2).
In C# you can indeed emit code at run-time and create new classes dynamically, but they are new classes, they do not replace an existing class. What I'd like to do is to transform the class at load-time, like you can do in Java with the ClassFileTransformer.
About modifying a method's signature: yes, you're right. I should have mentioned that in my case I don't want to modify the class' interface, but rather the content of its methods.
Your answer was really helpful. Thank you :)
Are you asking about (1) true class replacement at run-time, or (2) facilities to transform the class when it's loaded or (3) languages which support dynamic class loading ?
Java support dynamic class loading with ClassLoader, transformation with ClassFileTransformer, but no true class replacement.
I'm not sure for C#, but I think you can emit code at run-time and create new class dynamically, so you can achieve (3) and probably (2).
True class replacement is mostly supported only by dynamic language, e.g. Smalltalk, Ruby, I guess Python and a few others. This requires the transformation of the instances of the class to match the new shape. They usually initialize the new fields to nil if the class changes.
AFAIK, dynamic languages ported to the JVM make extensive hacking of ClassLoader to support class replacement at run-time. For JRuby, see A first taste of invoke dynamic to get more pointers how they do it now, what's problematic and how the upcoming invokedynamic might help.
This is not offered in statically typed languages because of the complication with the type system. If a method signature change in a class, other existing classes already loaded might not necessary comply with the new method signature which is not safe. In java you can however change a method as long as the signature is the same using the Java Platform Debugger Architecture.
There have been some attempt to add this feature to Java, and/or statically typed languages:
Runtime support for type-safe dynamic Java classes
Supporting Unanticipated Dynamic Adaptation of Application Behaviour
A Technique for Dynamic Updating of Java Software
This paper provide a general overview of related problems
Influence of type systems on dynamic software evolution
Not sure exactly if that address you initial question, but these pointers might be interesting for your thesis anyway.
The Java language doesn't support class file replacement. The JVM exposes the feature via the classes you mention. Therefore all languages which have been ported to the JVM can take advantage of it.
Erlang supports hot code swapping, and if you are looking also for theoretical frameworks that model dynamic class updates, you can take a look at the Creol language (interpreted).
Objective-C's runtime library supports dynamic construction and registration of classes, lazy method registration and "method swizzling" by which method implementations can be switched at runtime. Previous versions supported "Class swizzling" by which a class could be substituted for another at runtime, but now method swizzling is used instead. Here's the reference doc.
I'm terribly tired of checking all my arguments for null, and throwing ArgumenutNullExceptions when they are.
As I understand it, C# 4.0 enables some design by contract constructs. Will it be possible to specify that a method will not accept null arguments in C# 4.0?
Also, is there anything I can do in the meantime (maybe an attribute?) to avoid this monotonous task of checking for null and throwing?
You can create a NotNull<T> generic class that helps, but there are some side effects. See Robert Nystrom's blog post.
Rick Brewster describes a good solution for concise, declarative style parameter checking in this post,
http://blog.getpaint.net/2008/12/06/a-fluent-approach-to-c-parameter-validation/
Avoids use of reflection (drawback of DbC) and creates no overhead for non-exceptional code path.
Like how he uses extension methods to allow what appears to be instance method calls on null objects. Very clever bit of coding IMO.
If you are sold on DbC, Google Spec# and PostSharp.
Not sure about native DbC constructs in C# 4.0 but Microsoft is going to release cross-language Contracts library.
You can download version for MSVS2008 here.
As an alternative to the already given answers, it is worth looking into the Null Object design pattern.
The essence of this design pattern is that once the "null object" is created, there is no further need to perform any checks for null and the methods of the null object implement the behavior desired whenever a null (otherwise) would have been passed vs a reference to a "real object".
This design pattern does not depend on C# 4.0 and in fact can be easily implemented in almost any OO programming language.
I have just started using Code Contracts its a new feature in C# 4.0 you need to download an addin from MS to allow you to see it in your project settings. Details here ->
http://research.microsoft.com/en-us/projects/contracts/