The qt documentation is poor in QAndroidJniObject object. Could you possibly tell me what the difference between callStaticObjectMethod and callStaticMethod is and when should I use them?
If you have any working example, It would be appreciated if address them in you answers. (like Q notifier)
Thank you
As I've mentioned in a comment, the callStaticMethod is used with primitive types (which are listed here). This function returns the type you requested (ex. jint) not QAndroidJniObject.
And callStaticObjectMethod is used with methods returning an object type (which are listed here). It returns the QAndroidJniObject.
You can find example code in Qt unit test files on their git repository
Related
I am currently trying to convert a program that previously used AdaCore's ASIS library to be compatible with Libadalang instead. Does anyone know of a direct translation for the Element_Flat_Kinds type and corresponding functions or know of resources for converting between the two?
In order to create a simple annotation that logs function calls, I'm trying to grab the following attributes from a function that has said annotation:
Function name
Parameter names
Parameter values
What I have so far uses KCallable as a value, which makes grabbing the name and names from the list of KParameter fairly simple. However, I cannot figure out how to get the values of said parameters to make the log statement more contextual.
Does anyone have ideas on grabbing these parameters values within the annotation? It doesn't need to use KCallable, that just seemed like the most intuitive receiver.
You will need a different approach. Annotations and parameter type are a compile time features while values are a runtime feature.
What you will have to do is use a bytecode processing framework like ASM or google "aspect oriented programming". That allows you to examine the generated bytecode and modify if before the JVM tries to execute it.
The other approach is to write a Kotlin compiler plugin which generates the necessary code (google "Writing Your First Kotlin Compiler Plugin")
This blog post contains an example for Java and Spring using the AOP approach: https://solocoding.dev/blog/eng_spring_centrlize_logging_with_aop
I recommend the compiler plugin because the other approach is much more complicated, brittle and badly documented. Use AOP only if you find a framework which already contains all the features you need.
I have haxe code like this:
var fn:String->Int = function(s:String):Int{
return 1;
}
getParameterType(fn,1);//Should return String as it is first parameter of fn
what should function getParameterType code look like?
The Haxe Reflection APIs can be found here: Reflect and Type.
Looking through them, there doesn't seem to be any way to check the types of arguments on functions, probably because this information isn't available at runtime on many of the platforms. Javascript for instance is loosely typed, and the information you are looking for is not included by default.
So you have three options:
Use RTTI (Run Time Type Info). If a class is marked with #:rtti metadata (in Haxe 3, or if it implements haxe.rtti.Infos in Haxe 2), then information about that class, including the types of function parameters, is available in Xml format at run time. You will have to look at the Xml to figure out what the argument is. This will only work for functions which are attached to classes though, it won't work for anonymous functions.
Use macros. This is outside the scope of my answer, but maybe ask on the Haxe mailing list if you need help :) If the argument type is known at compile time, it can be made known to macros, and you can probably save that information back somewhere so it is available at run time.
Figure out another usage that doesn't require you to know the type :)
Of course, if you only need the information at compile-time, not at run-time, you can do: $type(fn) anywhere in your code and when you compile it will let you know the exact type signature of "fn".
I'd like to use the xref information from a GPS Ada project to generate lists of the variables defined for each package spec and body. I need to exclude any variables defined inside of subprograms.
I can see this information in GPS's "Project View" which shows the literals, package, pragmas, types, and variables defined in each file. However, the information is not selectable for cut/paste. How do I generate this in text form?
GPS is customised using Python. The provided scripts are in {installation}/share/gps/library; it looks as though unused_entities.py might be a good start. Or, there's a chapter on "Customizing and Extending GPS" in the GPS documentation.
[Edit]
Or, even better, look at the example globals.py in {installation}/share/examples/gps/python. A quick poke through the documentation (accessed in GPS via Help/Python extensions) suggests you're looking for GPS.Entities e where e.category() is "object".
Since you mention GPS, have you tried Tools->Documentation->Generate project?
This will generate html, with hyperlinks etc, similar to Javadoc.
SciTools' Understand product can extract this information, although it's rather pricey. Though if you're working with a mound of legacy code, it's well worth the money--it has saved my bacon on more than one occasion.
In principle, I could keep these extensions not-exported, and this would also allow me to not-add redundant documentation for these already well-documented methods, while still also passing R CMD check myPackage without any reported WARNINGs.
What are some of the drawbacks, if any? Is this possibly recommended to keep extensions of basic methods compartmentalized within the package that defines them? Alternatively, will this make it more difficult for another package to depend on mine, if certain core method-extensions are not exported?
For example, if I don't document and don't export the following:
setMethod("show", "myPackageSpecialClass", function(object){ show(NA) })
I'm trying to flesh-out some of these finer details of best-practices with namespaces and base method extensions.
If you don't export the methods, then users (either at the command line or trying to use your classes and methods in their own package via imports) won't be able to use them -- your class will be displayed with the show,ANY-method.
You are not documenting the generic show, but rather the method appropriate for your class, show,myPackageSpecialClass-method. If in your NAMESPACE you
import(methods)
exportMethods(show)
(note that there is no way to export just some methods on the generic show) and provide no documentation, R CMD check will complain
* checking for missing documentation entries ... WARNING
Undocumented S4 methods:
generic 'show' and siglist 'myPackageSpecialClass'
All user-level objects in a package (including S4 classes and methods)
should have documentation entries.
See the chapter 'Writing R documentation files' in the 'Writing R
Extensions' manual.
Your example (I know it was not meant to be a serious show method :) ) is a good illustration for why methods might be documented -- explaining to the user why every time they try and display the object they get NA, when they were expecting some kind of description about the object.
One approach to documentation is to group methods with the class into a single Rd file, myPackageSpecialClass-class.Rd. This file would contain an alias
\alias{show,myPackageSpecialClass-method}
and a Usage
\S4method{show}{myPackageSpacialClass}(object)
This works so long as no fancy multiple dispatch is used, i.e., it is clear to which class a method applies. If the user asks for help with ?show, they are always pointed toward the methods package help page. For help on your methods / class, they'd need to ask for that specific type of help. There are several ways of doing this but my favorite is
class ? myPackageSpecialClass
method ? "show,myPackageSpecialClass"
This will not be intuitive to the average user; the (class|method) ? ... formulation is not widely used, and the specification of "generic,signature" requires a lot of understanding about how S4 works, including probably a visit to selectMethod(show, "myPackageSpecialClass") (because the method might be implemented on a class that myPackageSpecialClass inherits from) or showMethods(class="myPackageSpecialClass", where=getNamespace("myPackage")) (because you're wondering what you can do with myPackageSpecialClass).