I have a program in vb.net (VS 2017) using 4.7 framework, where a function is taking too long to process, interrupting message pumping and causing a timeout error. To solve this I want to run the function asynchronously, using tasks and await. (new to me). I understand that to do that I need to create an asynchronous function (using the async keyword) which uses await to call another asynchronous function which then does the processing. The problem is how to make my own function asynchronous, which internally uses no predefined asynchronous process called by await. To do that it seems I need to have a GetAwaiter defined for my function making it callable using await. Here is where I get stumped. I have searched the web, and looked for books to cover this topic, and I come up short. All the web examples are in C# (which I am not very conversant in), and I can't wrap my head around the C# code examples I have found for creating a GetAwaiter. As an example, from a blog by Stephen Toub there is this:
public static TaskAwaiter GetAwaiter(this DateTimeOffset dateTimeOffset)
{
return (dateTimeOffset – DateTimeOffset.UtcNow).GetAwaiter();
}
to create a GetAwaiter for the DateTimeOffset function. I don't understand the declarative line, specifically the TaskAwaiter GetAwaiter twin and the contents of the parenthesis following the GetAwaiter keyword. I do think that 'this' refers to sender in vb, DateTimeOffset is the name of the function getting the GetAwaiter, and dateTimeOffset is a value being passed, but I don't understand that combination of function names and values inside a paren. How can this line be rewritten in vb? Are there any good, comprehensive books, articles, etc covering the task/await functionality - particularly when you have to create a new asynchronous function, one that is not pre-packaged and included as part of .net, and written including vb examples. I found a very informative youtube presentation by Michael Kennedy, but as in all other examples I've found, it relies on a predefined async function that can be called using await. I need to get my head above water - which way is the surface?
Related
In Alan Donovan and Brian Kernighan's "The Go programming language" book p333 (section 12.3 Display, a recursive value printer), it is mentioned that
Where possible, you should avoid exposing reflection in the API of a package. We'll define an unexported function display to do the real work of the recursion, and export Display, a simple wrapper around it that accepts an interface{} parameter.
func Display(name string, x interface{}) {
fmt.Printf("Display %s (%T):\n", name, x)
display(name, reflection.ValueOf(x))
And the display function prints different contents depending on the Kind of the input reflection value.
I have two questions
Why is it better to not expose the reflection in the package API?
Why is using an unexposed display function considered as not exposing reflection in the API? Don't we still call reflection.ValueOf() in Display?
I guess I don't know the definition of "exposing reflection in the package API". Does it just refer to the function arguments or both arguments and content? If it's the former case, then there seems no need to define display since the signature of Display is x interface{}. If it's the latter case, why is it better?
In the book's example
In the book's example, it is because the usage of reflection is an implementation detail. You should always try to hide the implementation details, so you may change the implementation at any time without breaking the "public" API of the package. If you export / add something to the API of your package, you have to carry that for the rest of your life (given you don't want to make backward-incompatible API changes, which is really bad in general).
In general
"interface{} says nothing" – Rob Pike. Given that, reflect.Value says even less. Unless you have a good reason (can't think of any outside of the reflect package itself), you shouldn't create public functions that expect reflect.Value as their arguments.
Even if you have a "general" function that must take a value of any type, interface{} is preferred as then at least the clients can pass what they have as-is, without having to wrap them in reflect.Value.
I'm tying to implement a novel way of overriding functions based on which DLLs I have loaded. In this model, I have a list of class instances from First = Highest Priority to Last = Lowest priority.
Any of those classes may implement a Hook function or callback. I'm currently at the stage where I can pass a string to a function, and then call it - my library convention looks like this:
Dim hookclasses as HooksList
Dim callable as Object
hookclasses.Add(new ClassA)
hookclasses.Add(new ClassB)
'... etc.
if hookclasses.Has("MyHookFunction", callable) then
callable.MyHookFunction()
end if
This all works, but I'd like to reduce typos by leveraging Intellisense. I've already thought of popping the strings into a class containing constant strings, so I'm after something better than that.
Ideally I'd like to have a fallback class that implements all of the hook functions (even if it simply returns), and if the language supported it, I'd like to do the following:
if hookclasses.Has(NameOf(FallbackClass.MyHookFunction), callable) then ...
Clearly there is no 'NameOf' operator, and I don't know how to write a NameOf function.
Is this possible?
Thanks.
Check this article nameOf (C# and Visual Basic reference)
https://msdn.microsoft.com/en-us/library/dn986596.aspx
It does exactly what you want. And before that String Litterals were almost the only option.
Edit :
Question was : "Clearly there is no 'NameOf' operator, and I don't know how to write a NameOf function."
If I understand your problem right, you have a list of classes that you fetched from dynamically loaded DLL, point is you don't know if a class implements all of the hooks or only a few.
If you use an interface, like IHookable and put all the hook functions in there, it means all the DLL have to implement all the hook functions, which is not what you want.
And (if I understand it properly) if the first class in list does not implement the hook, you check the second one and so on. So with an interface you wouldn't know if the hook is implemented or not.
I'm using NUnit to verify some code and have a problem reporting helpful information. My tests go something along the following lines:
Assert::IsTrue(myClassInstance.SomeMethodToTest(), "Test failed: {0}", myClassInstance.LastError);
The problem is that the LastError property is evaluated before the method is tested so the last error is blank.
Is there any way to delay the evaluation of the last error to give the function some more meaningful output?
Well, that's a big bummer, but you are invoking Undefined Behavior here. NUnit was originally designed for Java, ported pretty well to C# and VB.NET. Languages that promise strict left-to-right function argument evaluation order in their language spec. So that Assert.IsTrue() method has well defined behavior in those languages.
But not in C++/CLI, it takes advantage of the UB rule in C++. No doubt inspired by the [ParamArray] for the 3rd argument, it first polishes off that one before evaluating the other arguments. You get right-to-left order. Shooting off the hip, I'd say that this has something to do with varargs emulation.
Not so sure what to recommend, sailing around UB is forever tricky. You can technically provide your own overloads of Assert::IsTrue() with one or more Object^ arguments. The compiler will pick those instead of the [ParamArray] overload. Or avoid the [ParamArray] overload completely and use String::Format() to generate the message argument instead. You'll now get left-to-right. That's still UB however, it looks okay but I can't promise this will work with every possible set of argument expressions.
Ouch, sorry.
When using m.module, I often would like to provide arguments to the controller constructor so that the first rendering starts with the right data. However, the Mithril documentation and examples always show module.controller() and module.vm.init() without parameters.
To go around this issue and have module.controller(initData) I've resorted to use this small utility function to wrap and extend the existing m.Module:
var mModule = function (dom, mod, arg) {
return m.module(dom, {
view: mod.view,
controller: mod.controller.bind(mod.controller,arg)
});
};
Questions:
Is this an anti-pattern? Is there an alternate recommended way instantiate the module with custom external data?
Would this cause issues with m.route? I saw some mentions of recursive calls in the source code but could not get my head around it.
Following the 2 points above, is the lack of parameter for m.module a deliberate design choice?
Oh...and thanks to all involved for the existing documentation and discussions.
No, it's not an anti-pattern, and it's an idea that is explored in one of the blog articles, and also by Moria (a router extension library for Mithril)
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.