I have a C++ method that takes variable argument as init param. Something like
MyMethod(std::wchar_t*, ...)
Can someone please let me know how can we write a WinRT component wrapper to expose the variable arguments?
WinRT metadata does not support vararg functions, so there is no good way to do this. The answer therefore depends on what the function actually does. Assuming it is some kind of string formatting function I would suggest wrapping it with something like:-
MyMethod(Platform::String^, Windows::Foundation::Collections::IVector<Platform::Object^>^ params);
This will allow you to take the variable arguments.
The problem of course is that this has completely different semantics from what you have. The caller is going to have to pack up an array, and you won't be able to call your existing method easily with the arguments from the vector.
Related
I am using a third-party library that is a wrapper over some C functions. Unfortunately, nearly all of the Go functions are free (they don't have a receiver, they are not methods); not the design approach I would have taken but it is what I have.
Using just Go's standard "testing" library:
Is there a solution that allows me to create tests where I can mock functions?
Or is the solution to wrap the library into structures and interfaces, then mock the interface to achieve my goal?
I have created a monte carlo simulation that also process the produced dataset. One of my evaluation algorithms looks for specific models that it then passes the third-party function for its evaluation. I know my edge cases and know what the call counts should be, and this is what I want to test.
Perhaps a simple counter is all that is needed?
Other projects using this library, that I have found, do not have full coverage or no testing at all.
You can do this by using a reference to the actual function whenever you need to call it.
Then, when you need to mock the function you just point the reference to a mock implementation.
Let's say this is your external function:
// this is the wrapper for an external function
func externalFunction(i int) int {
return i * 10 // do something with input
}
You never call this directly but instead declare a reference to it:
var processInt func(int) int = externalFunction
When you need to invoke the function you do it using the reference:
fmt.Println(processInt(5))
Then, went you want to mock the function you just assign a mock implementation to that reference:
processInt = mockFunction
This playground puts it together and might be more clear than the explanation:
https://play.golang.org/p/xBuriFHlm9
If you have a function that receives a func(int) int, you can send that function either the actual externalFunction or the mockFunction when you want it to use the mock implementation.
(defn domready [handler]
(.addEventListener js/window "DOMContentLoaded" handler))
I borrowed this code from here. The problem is I don't totally understand what's going on. JS interop is still a bit of a mystery to me.
.addEventListener
So this is clearly a procedure call, but it's kind of generic. It's like Clojurescript took everything that was inside an object, took it out, and you use it to call that method on "objects". As long as that "object" has the ".addEventListener" property it will call this. Is that what it's doing? Why not use a keyword instead? like (:addEventListener domElement) that seems more logical to me.
js/window
What is this? Is it a namespace or an object? Are they the same thing?
"DOMContentLoaded"
A string, that's familiar.
handler
Also familiar, but does it have a notion of this? Not that I'm really going to miss this.
.addEventListener
So this is clearly a procedure call, but it's kind
of generic. It's like Clojurescript took everything that was inside an
object, took it out, and you use it to call that method on "objects".
As long as that "object" has the ".addEventListener" property it will
call this. Is that what it's doing? Why not use a keyword instead?
like (:addEventListener domElement) that seems more logical to me.
Your mental model about how this works is mostly fine. What it does when it compiles is move the function name to be run as a method on the first argument.
(.method obj ...args) get's transformed to obj.method(...args)
This type of interop comes from the parent language Clojure.
On why do we have an explicit version of calling the function that's not Clojure idiomatic, I think the idea is to have clear separation between what is native Clojure code with Clojure semantics (immutability, friendly to CLJ data structures, etc) and what is interoperating with the host environment (mutable, not friendly to CLJ data structures, etc).
In my opinion it is better to have clear separation between those two given how different the semantics of CLJS and the host platforms are. For me explicitness is better than implicit in this case (it is easy to spot looking at the code what is JS code in CLJS, and what is pure CLJS).
js/window
What is this? Is it a namespace or an object? Are they the same thing?
Both, js/ is accessing the namespace js, which is where CLJS puts the JS namespace (since there is only one and global). window is just grabbing the window variable from the js namespace.
This is no different from how you access variables in other namespaces in CLJS. If you (def a 1) in (ns cljs.test) and then run cljs.test/a that will give you 1. Same form, ns/something-in-that-ns.
"DOMContentLoaded"
A string, that's familiar.
\o/
handler
Also familiar, but does it have a notion of this? Not that I'm really going to miss this.
Not sure what this has to do with handler. It is just a higher order function passed into domready as a parameter, like you would do in JS: function domready (onReady) { window.addEventListener("DOMContentLoaded", onReady) }
I hope this helps, if you want to try it out live and learn some more, maybe visit the Talking with JS on the Diving into ClojureScript tutorial, or maybe check this section of the lt-cljs-tutorial.
I'm just learning clojurescript so I don't really know if it is the correct answer but I've done it in the following way:
(defn handler [] (js/console.log "ready"))
(js/document.addEventListener "DOMContentLoaded" handler)
which is then translated to
cljs.user.handler = (function cljs$user$handler(){
return console.log("ready");
});
document.addEventListener("DOMContentLoaded",cljs.user.handler);
to check how clojurescript translate code I've used KLIMPSE http://app.klipse.tech/
.addEventListener is a method call on the global Javascript object js/window. This method call takes two parameters: "DOMContentLoaded" and handler.
When you are doing interop (either Java or Javascript) you really are calling methods on objects. There are macros behind what is happening here. What is straight after the ( is a verb, which I usually think of as a function call (although it might also be a macro or a special form). When doing interop what comes after the verb is the instance, and after that the parameters.
If it were straight Javascript it would look like this:
function domready(handler){
window.addEventListener("DOMContentLoaded" handler);
}
Say I have a project, I have several CFC's in that project. For the sake of the example, I have a debugging function general.cfc and I want to use that function in mandrill.cfc without having to copy and paste the code into the latter cfc. I've googled this until I can google no more and I know I need to post it here.
Anyone care to take me to school?
This is how I would do it
<cfset var objGeneral = createObject("component","general")>
Then if you have a function in general.cfc called getName() you can call it by saying objGeneral.getName()
You should look at the notion of dependency injection, and you should specifically look at how ColdSpring implements it in the context of ColdFusion (or DI/1).
Basically you have an init() argument in Mandrill which would take a General object, and then you set the General object into the variables scope of the Mandrill object, using its methods via variables.general.
That said, this works best on singleton objects. If you need to do this sort of thing on a transient object, I'd just instantiate the General object as needed within your Mandrill code (ie: now Matt Busche is suggesting).
My solution was to have mandrill.cfc extend the general.cfc component:
<cfcomponent extends="general" name="mandrill" ...>
See also CreateObject
I am trying to use Mootools together with TypeScript. Mootools, and some modern browsers support .bind method, which is polymorphic.
How can I properly declare this feature in a *.d.ts file, to be able to use constructs like [1,2].map(this.foo.bind(this)); ?
I know I can avoid such constructs by using lambdas, but sometimes I do not want to.
Perhaps there is a mootools.d.ts file somewhere which I could download instead of reinventing it myself?
TypeScript's lib.d.ts already defines the bind function's signature in the Function interface as follows:
bind(thisArg: any, ...argArray: any[]): Function;
I don't think there's any better way of doing it until generics get added to the language.
For the time being though, if you want to use bind and the recipient of the resulting function expects a specific signature, you're going to have to cast the function back to that signature:
var bfn : (p: number) => string;
bfn = <(p: number) => string> fn.bind(ctx);
There's a growing list of definition files being tracked here.
As for generating methods pre-bound to their this pointer in TypeScript I've suggested two ways of doing this. 1) a simple base class I defined at the end of this thread. and 2) a more advanced mixin & attribute system here.
What are useful definitions for the common methods of passing a method or function as data, such as:
Delegates
Closures
Function pointers
Invocation by dynamic proxy and
First class methods?
Function pointers lets you pass functions around like variables. Function pointer is basically legacy method to pass function around in languages that don't support first-class methods, such as C/C++.
First class methods Basically means you can pass functions around like variables. Methods (loosely) mean functions. So this basically means first class functions. In simplest terms, it means functions are treated as "first class citizens", like variables. In the old days (C/C++), because we can't directly pass a function around, and we had to resort to workarounds like function pointers, we said functions weren't first-class citizens.
Delegates is C#'s answer to first-class methods. Delegates are somewhat more powerful because it involves closures, consider the following code snippet:
void foo( int a )
{
void bar() { writefln( a ); }
call( &bar );
}
void call( void delegate() dg ) { dg(); }
int main( char[][] args ) {
foo( 100 );
}
Notice that bar can reference the local variable a because delegates can use closures.
Closures can be very confusing at first. But the lazy-man's definition can be really simple. It basically means a variable can be available in the human-expected way. Put in other words, a variable can be referenced in places where they look like they would be present, by reading the structure of the source code. For example, looking at the code fragment above. If we didn't have closure, bar would not be able to reference a because a was only local to foo, but not bar, which is another function.
Dynamic Proxy is the odd one out. It doesn't belong to these items. Explaining it requires some very long text. It stems from the famous Proxy Pattern. The problem with Proxy Pattern was that the Proxy class needs to be implementing the same interface as the Subject. Dynamic Proxy basically means using reflective approach to discover the Subject's method so that the ProxyPattern can be freed from being tied to the Subject's interface.
just the ones i know about:
Function pointers: just that, a pointer to a piece of code. you jump to it, it executes. typed languages can enforce some parameter passing convention (i.e. C declarations)
Closures: a function with some state paired. most naturally written in lexically scoped languages (i.e. Scheme, JavaScript, Lua). several closures can share the same state (or part of it), making it an easy way to implement OOP.
First class methods: a closure created from an object instance and a method. some languages with both closures and a native OOP (Python, JavaScript) can create closures automatically.
Closure is a programming language concept. Delegate is its realization in MS.NET.
A Delegate in MS.NET is a strongly typed pointer to an object's method (a delegate instance points to both - an object and its method). There is also a way to combine several void delegate instances into one.