I'm messing around with CQLinq and was trying to write a query to find the types in my project that are used as generic type params to a 3rd party generic method.
To be more specific, we use a 3rd party library called AutoMapper which has a static generic method, Mapper.CreateMap<T1, T2>(). Is it possible to write a query to find which types from my code are used as params to the CreateMap method?
Thanks.
Related
In my project, I have multiple model classes consisting of their own JSON parsing methods, how can I use generic type to increase code reusability.
NOTE: for HTTP request am using DIO package
The generic type you'd be referencing would have to capture the same specifics as the portion of the classes that are performing JSON parsing and serializing in your existing classes. You're just introducing a complicated interaction.
It's very hard to get past the fundamental nature of Dart, in that the member variable access cannot be somehow performed with the string names of those members. This isn't JavaScript or Perl or Ruby. :) So compile-time builder systems like json_serializable, or edit-time processing like Dart Data Class Generator for VSCode, are essential to the process.
I'm trying to add some re-usability to a Java library which has some common methods across classes, but whose methods are not part of a common hierarchy. I'm pretty certain I've seen it previously that Scala allows non-trait based contracts for parameter classes, but for the life of me I cannot find this information anywhere at the moment.
Does my memory serve me correctly? Would anybody be able to point me in the right direction for documentation on said language feature (if I am not mistaken)?
For some added context, I'm trying to reduce duplicate code when using some Google Java libraries where things like getNextPageToken(), setPageToken(), etc. are common between many classes, but are not implemented further up in the hierarchy where I would have the option to specify a common parent class as the parameter type. So essentially I'd like to enforce that these methods exist and offload the duplicate request & pagination code to a common function using said method contracts.
You probably want to use structural types:
example:
def method(param: { def getNextPageToken(): Unit })
param will be required to have getNextPageToken method with no parameters and returning Unit. It is handled using reflection.
I'm reading "Practical Common Lisp" and I wonder if Common Lisp supports Duck-Typing like e.g. Ruby?
In Ruby it's possible to call a method on an object regardless of the class as long as it implements a method with the name and argument list that the caller assumes.
What about CLOS? Is it possible to call methods on objects without considering their class simply by assuming that a generic function will cope with it. Perhaps duck-typing is not needed because CLOS doesn't follow a message passing philosophy and methods are not bound to classes.
Perhaps duck-typing is not needed because CLOS doesn't follow a message passing philosophy and methods are not bound to classes.
That is exactly the case. Every generic function can be dynamically specialized for a certain class. There can also be a default implementation. And since Lisp uses dynamic typing, every function can be called with arguments of any type, and for generic functions the dispatch decision, based on the type of argument, is taken at runtime.
I'm looking at implementing a JSON-RPC based web service in Scala using finagle. I'm trying to work out how best to structure the RPC invocation code (ie. taking the deserialized request and invoking the appropriate method).
The service needs to be able to spit out a help page on all the possible requests accepted and their parameters. In Java, I would simply use annotations (to both expose and document functions) and then have the RPC service reflect on the appropriate classes, detect all exposed methods and then use the reflected MethodInfo's to invoke the functions where appropriate.
What is the idiomatic Scala way to achieve something similar? Should I use a message-passing approach (ie. just pass a request object into an actor, have it determine if it can invoke it, etc.)
We had success doing something similar to the approach suggested by #Jan above. More specifically, we defined a parent class for all request objects which takes the expected return type as a type parameter. Going one step further, we're generating our protocol IDL and serialization bindings by reflecting on API objects (little more than sets of requests).
In the future, the experimental typed channels feature in Akka may help with some of the mechanics.
In this video from Google IO 2009, the presenter very quickly says that signatures of methods should return concrete types instead of interfaces.
From what I heard in the video, this has something to do with the GWT Java-to-Javascript compiler.
What's the reason behind this choice ?
What does the interface in the method signature do to the compiler ?
What methods can return interfaces instead of concrete types, and which are better off returning concrete instances ?
This has to do with the gwt-compiler, as you say correctly. EDIT: However, as Daniel noted in a comment below, this does not apply to the gwt-compiler in general but only when using GWT-RPC.
If you declare List instead of ArrayList as the return type, the gwt-compiler will include the complete List-hierarchy (i.e. all types implementing List) in your compiled code. If you use ArrayList, the compiler will only need to include the ArrayList hierarchy (i.e. all types implementing ArrayList -- which usually is just ArrayList itself). Using an interface instead of a concrete class you will pay a penalty in terms of compile time and in the size of your generated code (and thus the amount of code each user has to download when running your app).
You were also asking for the reason: If you use the interface (instead of a concrete class) the compiler does not know at compile time which implementations of these interfaces are going to be used. Thus, it includes all possible implementations.
Regarding your last question: all methods CAN be declared to return interface (that is what you ment, right?). However, the above penalty applies.
And by the way: As I understand it, this problem is not restricted to methods. It applies to all type declarations: variables, parameters. Whenever you use an interface to declare something, the compiler will include the complete hierarchy of sub-interfaces and implementing classes. (So obviously if you declare your own interface with only one or two implementing classes then you are not incurring a big penalty. That is how I use interfaces in GWT.)
In short: use concrete classes whenever possible.
(Small suggestion: it would help if you gave the time stamp when you refer to a video.)
This and other performance tips were presented at Google IO 2011 - High-performance GWT.
At about the 7 min point the speak addresses 'RPC Type Explosion':
For some reason I thought the GWT compiler would optimize it away again but it appears I was mistaken.