To implement "method-missing"-semantics and such in C# 4.0, you have to implement IDynamicObject:
public interface IDynamicObject
{
MetaObject GetMetaObject(Expression parameter);
}
As far as I can figure out IDynamicObject is actually part of the DLR, so it is not new. But I have not been able to find much documentation on it.
There are some very simple example implementations out there (f.x. here and here), but could anyone point me to more complete implementations or some real documentation?
Especially, how exactly are you supposed to handle the "parameter"-parameter?
The short answer is that the MetaObject is what's responsible for actually generating the code that will be run at the call site. The mechanism that it uses for this is LINQ expression trees, which have been enhanced in the DLR. So instead of starting with an object, it starts with an expression that represents the object, and ultimately it's going to need to return an expression tree that describes the action to be taken.
When playing with this, please remember that the version of System.Core in the CTP was taken from a snapshot at the end of August. It doesn't correspond very cleanly to any particular beta of IronPython. A number of changes have been made to the DLR since then.
Also, for compatibility with the CLR v2 System.Core, releases of IronPython starting with either beta 4 or beta 5 now rename everything in that's in the System namespace to be in the Microsoft namespace instead.
If you want an end to end sample including source code, resulting in a dynamic object that stores value for arbitrary properties in a Dictionary then my post "A first look at Duck Typing in C# 4.0" could be right for you. I wrote that post to show how dynamic object can be cast to statically typed interfaces. It has a complete working implementation of a Duck that is a IDynamicObject and may acts like a IQuack.
If you need more information contact me on my blog and I will help you along, as good as I can.
I just blogged about how to do this here:
http://mikehadlow.blogspot.com/2008/10/dynamic-dispatch-in-c-40.html
Here is what I have figured out so far:
The Dynamic Language Runtime is currently maintained as part of the IronPython project. So that is the best place to go for information.
The easiest way to implement a class supporting IDynamicObject seems to be to derive from Microsoft.Scripting.Actions.Dynamic and override the relevant methods, for instance the Call-method to implement function call semantics. It looks like Microsoft.Scripting.Actions.Dynamic hasn't been included in the CTP, but the one from IronPython 2.0 looks like it will work.
I am still unclear on the exact meaning of the "parameter"-parameter, but it seems to provide context for the binding of the dynamic-object.
This presentation also provides a lot of information about the DLR:
Deep Dive: Dynamic Languages in Microsoft .NET by Jim Hugunin.
Related
I have a DLL from a vendor that I Need to invoke from C#. I know that C# data classes are not directly compatible with C++ data types.
So, given that I have a function that receives data and returns a "string".
(like this)
string answer = CreateCode2(int, string1, uint32, string2, uint16);
What must I do to make the input parameters compatible, and then make the result string compatible?
Please - I have never done this: Don't give answers like "Use P/Invoke" or "Use Marshal" I need a tutorial with examples.
All the P/Invoke examples I have seen are from .NET Framework 1.1, and Marshall (without a tutorial) is totally confusing me.
Also, I have seen some examples that tell me when I create my extern function to replace all the datatypes with void*. This is makes my IDE demand that I use "unsafe".
This isn't quite a tutorial but it's got a lot of good information on using P/Invoke
Calling Win32 DLLs in C# with P/Invoke
It'll give you an idea of the terminology, the basic concepts, how to use DllImport and should be enough to get you going.
There's a tutorial on MSDN: Platform Invoke Tutorial.
But it's pretty short and to be honest the one I've mentioned above is a much better source of information, but there's a lot of it on there.
Also useful is the PInvoke Signature Toolkit, described here .
And downloadable here.
It lets you paste in an unmanaged method signature, or struct definition and it'll give you the .NET P/Invoke equivalent. It's not 100% perfect but it gets you going much quicker than trying to figure everything out yourself.
With regards to Marshalling specifically, I would say start simple.
If you've got something that's some sort of pointer, rather than trying to convert it directly to some .NET type in the method signature using Marshal it can sometimes be easier to just treat it as an IntPtr and then use Marshal.Copy, .PtrToString, .PtrToStructure and the other similar methods to get the data into a .NET type.
Then when you've gotten to grips with the whole thing you can move on to direct conversions using the Marshal attribute.
There's a good 3 part set of articles on marshalling here, here and here.
It's common in a lot of classes in JDK, just a few examples:
java.util.Properties
load0
store0
java.lang.Thread
start0
stop0
setPriority0
Usually they are private native methods (like in Thread class), but sometimes they are just private (Properties class)
I'm just curious if anybody know if there is any history behind that.
I believe they are named like that because equivalent functions with same names exist in the code and just to distinguish between native helper functions and public functions they decided to suffix them with 0.
in java.util.Properties both load, store and load0, store0 exist.
The 0 after the method name is done so to distinguish between public and private methods having same name .
Start function will call the start0 function.
Those functions which ends with 0 is private method.
And those which are not ending with number is public.
You can check in any of the library.
The use of zero suffixes on method names is just a convention to deal with cases where you have a public API method and a corresponding private method. In the Java SE libraries, this is commonly used for the native methods that provide the underlying functionality implemented by the classes. (You can see what is going on by looking at the OpenJDK source code.)
But your questions are:
Why some java methods in core libraries end with numbers?
Because someone thought it would be a good idea. It is not strictly necessary since they typically could have overloaded the public methods instead. And since the zero suffix matters are private, the naming of methods should not be relevant beyond the class and its native implementation.
I'm just curious if anybody know if there is any history behind that.
There is no mention of this convention in the original Java Style Guide. In fact, I think it predates Java. I vaguely recall seeing it in C libraries in 4.x BSD Unix. That was the mid 1980's. And I wouldn't be surprised if they adopted it from somewhere else.
ObjC has a very unique way of overriding methods. Specifically, that you can override functions in OSX's own framework. Via "categories" or "Swizzling". You can even override "buried" functions only used internally.
Can someone provide me with an example where there was a good reason to do this? Something you would use in released commercial software and not just some hacked up tool for internal use?
For example, maybe you wanted to improve on some built in method, or maybe there was a bug in a framework method you wanted to fix.
Also, can you explain why this can best be done with features in ObjC, and not in C++ / Java and the like. I mean, I've heard of the ability to load a C library, but allow certain functions to be replaced, with functions of the same name that were previously loaded. How is ObjC better at modifying library behaviour than that?
If you're extending the question from mere swizzling to actual library modification then I can think of useful examples.
As of iOS 5, NSURLConnection provides sendAsynchronousRequest:queue:completionHandler:, which is a block (/closure) driven way to perform an asynchronous load from any resource identifiable with a URL (local or remote). It's a very useful way to be able to proceed as it makes your code cleaner and smaller than the classical delegate alternative and is much more likely to keep the related parts of your code close to one another.
That method isn't supplied in iOS 4. So what I've done in my project is that, when the application is launched (via a suitable + (void)load), I check whether the method is defined. If not I patch an implementation of it onto the class. Henceforth every other part of the program can be written to the iOS 5 specification without performing any sort of version or availability check exactly as if I was targeting iOS 5 only, except that it'll also run on iOS 4.
In Java or C++ I guess the same sort of thing would be achieved by creating your own class to issue URL connections that performs a runtime check each time it is called. That's a worse solution because it's more difficult to step back from. This way around if I decide one day to support iOS 5 only I simply delete the source file that adds my implementation of sendAsynchronousRequest:.... Nothing else changes.
As for method swizzling, the only times I see it suggested are where somebody wants to change the functionality of an existing class and doesn't have access to the code in which the class is created. So you're usually talking about trying to modify logically opaque code from the outside by making assumptions about its implementation. I wouldn't really support that as an idea on any language. I guess it gets recommended more in Objective-C because Apple are more prone to making things opaque (see, e.g. every app that wanted to show a customised camera view prior to iOS 3.1, every app that wanted to perform custom processing on camera input prior to iOS 4.0, etc), rather than because it's a good idea in Objective-C. It isn't.
EDIT: so, in further exposition — I can't post full code because I wrote it as part of my job, but I have a class named NSURLConnectionAsyncForiOS4 with an implementation of sendAsynchronousRequest:queue:completionHandler:. That implementation is actually quite trivial, just dispatching an operation to the nominated queue that does a synchronous load via the old sendSynchronousRequest:... interface and then posts the results from that on to the handler.
That class has a + (void)load, which is the class method you add to a class that will be issued immediately after that class has been loaded into memory, effectively as a global constructor for the metaclass and with all the usual caveats.
In my +load I use the Objective-C runtime directly via its C interface to check whether sendAsynchronousRequest:... is defined on NSURLConnection. If it isn't then I add my implementation to NSURLConnection, so from henceforth it is defined. This explicitly isn't swizzling — I'm not adjusting the existing implementation of anything, I'm just adding a user-supplied implementation of something if Apple's isn't available. Relevant runtime calls are objc_getClass, class_getClassMethod and class_addMethod.
In the rest of the code, whenever I want to perform an asynchronous URL connection I just write e.g.
[NSURLConnection sendAsynchronousRequest:request
queue:[self anyBackgroundOperationQueue]
completionHandler:
^(NSURLResponse *response, NSData *data, NSError *blockError)
{
if(blockError)
{
// oh dear; was it fatal?
}
if(data)
{
// hooray! You know, unless this was an HTTP request, in
// which case I should check the response code, etc.
}
/* etc */
}
So the rest of my code is just written to the iOS 5 API and neither knows nor cares that I have a shim somewhere else to provide that one microscopic part of the iOS 5 changes on iOS 4. And, as I say, when I stop supporting iOS 4 I'll just delete the shim from the project and all the rest of my code will continue not to know or to care.
I had similar code to supply an alternative partial implementation of NSJSONSerialization (which dynamically created a new class in the runtime and copied methods to it); the one adjustment you need to make is that references to NSJSONSerialization elsewhere will be resolved once at load time by the linker, which you don't really want. So I added a quick #define of NSJSONSerialization to NSClassFromString(#"NSJSONSerialization") in my precompiled header. Which is less functionally neat but a similar line of action in terms of finding a way to keep iOS 4 support for the time being while just writing the rest of the project to the iOS 5 standards.
There are both good and bad cases. Since you didn't mention anything in particular these examples will be all-over-the-place.
It's perfectly normal (good idea) to override framework methods when subclassing:
When subclassing NSView (from the AppKit.framework), it's expected that you override drawRect:(NSRect). It's the mechanism used for drawing views.
When creating a custom NSMenu, you could override insertItemWithTitle:action:keyEquivalent:atIndex: and any other methods...
The main thing when subclassing is whether or not your behaviour completes re-defines the old behaviour... or extends it (in which case your override eventually calls [super ...];)
That said, however, you should always stand clear of using (and overriding) any private API methods (those normally have an underscore prefix in their name). This is a bad idea.
You also should not override existing methods via categories. That's also bad. It has undefined behaviour.
If you're talking about categories, you don't override methods with them (because there is no way to call original method, like calling super when subclassing), but only completely replace with your own ones, which makes the whole idea mostly pointless. Categories are only useful for safely extending functionality, and that's the only use I have even seen (and which is a very good, an excellent idea), although indeed they can be used for dangerous things.
If you mean overriding by subclassing, that is not unique. But in Obj-C you can override everything, even private undocumented methods, not just what was declared 'overridable' like in other languages. Personally, I think it's nice, as I remember in Delphi and C++ I used to “hack” access to private and protected members to workaround an internal bug in framework. This is not a good idea, but at some moments it can be a life saver.
There is also method swizzling, but that's not standard language feature, that's a hack. Hacking undocumented internals is rarely a good idea.
And regarding “how can you explain why this can best be done with features in ObjC”, the answer is simple — Obj-C is dynamic, and this freedom is common to almost all dynamic languages (Javascript, Python, Ruby, Io, a lot more). Unless artificially disabled, every dynamic language has it.
Refer to the wikipedia page on dynamic languages for longer explanation and more examples. For example, an even more miraculous things possible in Obj-C and other dynamic languages is that an object can change it's type (class) in place, without recreation.
I am currently designing the migration of my existing .NET / C# / WinForms project to a platform neutral solution and the most attractive alternative I have seen seems to be wxWidgets especially taking in consideration my familiarity with C++ and with MFC that appears to have a lot in common with it.
After going though the documentation and the sample code I need to clarify the following issue:
Is it a valid assumption that the way to develop a User Control (by C# terminology) in a wx environment is to derive a class from wxPanel , customize it and place it in a wxFrame?
If this is the case what is the wxFrame method to be used to add the wxPanel object to it ?
The only relative method I was able to find was wxWindow::AddChild but the documentation states that is mostly internal to wxWidgets and shouldn't be called by the user code.
To avoid confusion please note that my question is about a User Control and not a Custom Control (which is clearly addressed in the documentation)
I think you have to set the parent window in the constructor of your wxPanel-derived class and pass it to the inherited constructor (cf. wxPanel constructor)
A better solution, though, is to use sizers (see wx Sizers) for layouting.
And yes, imo you're right about wxPanelbeing (roughly) the equivalent of a C# UserControl.
I am looking for "typical" way one navigates MSDN to get a COM class to do what they want.
Example problem: I am looking for an API way to unblock a local file (remove internet zone/mark of the web from a file programmatically).
I found one post on stackoverflow.com that talked about clsid_persistentzoneidentifier. so i searched in MSDN and got to http://msdn.microsoft.com/en-us/library/ms537029(VS.85).aspx. What I am looking for,is what one does after they get to this url. From this location, I am not able to figure what the sequence of operations should be. How do I connect this IZoneIdentifier to IPersistFile? etc. There must be something basic that I am missing wrt COM related documentation. MSDN has interfaces and objects, but nothing that helps me visualize a "sequence" diagram of sorts. Nothing that will get me to understand which COM objects are from same class. hence can/or should be QueryInterfaced, adn which should be CoCreated.
The documentation for that indicates a few things.
The first is that you can call CoCreateInstance, passing CLSID_PersistentZoneIdentifier to get an implementation of these two interfaces:
IPersistFile
IZoneIdentifier
It also says:
Use IPersistFile to attach the object
to the target file and IZoneIdentifier
to examine or to manipulate the zone
ID.
That being said, you can look at the documentation for IPersistFile here:
http://msdn.microsoft.com/en-us/library/ms687223(VS.85).aspx
It shows that there is a Load method, which is what you want to call with the filename to load the implementation with details about the file.
From there, you can call QueryInterface on the IUnknown interface implementation to get the IZoneIdentifier interface and then call the Remove method on it to set the zone to the local machine.
For that purpose, if it's not obvious from the documentation, I like to find sample programs in which relevent APIs are used: either using Google, or perhaps from whichever of the Microsoft SDKs is relevent.
Microsoft SDKs, for example this one, include sample programs.