I have few module namespace xquery files which were used in multiple files. I want to have the namespaces in one common xquery file and import that file whereever I want to use.
Say for example,
I have process-lib.xqy, util-lib.xqy and query-lib.xqy.
I used to import these in multiple files like following,
import module namespace util = "util" at "util-lib.xqy";
import module namespace process = "process" at "process-lib.xqy";
import module namespace query = "query" at "query-lib.xqy";
Now I tried to use them in one common file named as common-import.xqy and import this file in multiple files.
when I tried this approach,
import module namespace common-import= "common-import" at "common-import.xqy";
It throws exception as prefix util has no namespace binding.
How to achieve this?
This is not possible, at least not in the way you want to do it and rightfully so. The XQuery spec doesn't allow this:
Module imports are not transitive—that is, importing a module provides access only to function and variable declarations contained directly in the imported module. For example, if module A imports module B, and module B imports module C, module A does not have access to the functions and variables declared in module C.
This is a deliberate design decision. If you want to have access in this way you could write a wrapper function for each function you want to access, e.g. in your common-import.xqy file you could have:
declare function common-import:test() {
util:test()
};
But of course this can require a tremendous amount of wrapper functions. I would recommend you stick simply to inserting all required libraries. I see no benefit in doing otherwise.
Related
I want to use the rule new as shown in some of the documentation examples, but I get the error:
ERROR: rule "new" unknown in module "Jamfile<path/to/my/module>"
What module should I import to access this rule ?
You need to import the class module.
Because class is also a language keyword you need to use quotes:
import "class" ;
then you can use class.new in your code
What is an XQuery to import module namespace in MarkLogic? How do you bind the namespace to the prefix admin?
import module namespace admin="http://marklogic.com/xdmp/admin" at "/MarkLogic/admin.xqy";
I tried it this way but getting error.
ServerEvaluationCall forestDataDirCall =
client
.newServerEval()
.xquery("xquery version \"1.0-ml\";\r\n" +
"xdmp:with-namespaces(admin,http://marklogic.com/xdmp/admin)
The import statement that you referenced does two things:
declares the namespace "http://marklogic.com/xdmp/admin" bound to the admin namespace-prefix
imports the "/MarkLogic/admin.xqy" library module that is bound to that admin namespace, so that it's functions can be used and referenced by the admin prefix.
You can also simply declare a namespace and bind it to a namespace-prefix
declare namespace admin="http://marklogic.com/xdmp/admin";
However, then you would not have those library functions available to be used.
It appears that this question is related to one of your other questions. In order to eval code using admin functions, you need to include the import statement in the XQuery that you want to evaluate:
ServerEvaluationCall forestDataDirCall = client.newServerEval()
.xquery('import module namespace admin="http://marklogic.com/xdmp/admin" at "/MarkLogic/admin.xqy"; admin:forest-get-data-directory(admin:get-configuration(), admin:forest-get-id(admin:get-configuration(), "' + forestName +'"))');
Is it possible to export and import Flow type definitions in CommonJS world similarly to ES6 like type imports/exports?
There is no CommonJS-style require for Flow, but Flow's import type/export type syntax can be used alongside CommonJS require calls.
Though the syntax looks similar, import type and export type are not actual JavaScript import/export statements. They must be stripped from your code before your code can be run in current browsers. If you use Babel to compile your code, for example, you use the transform-flow-strip-types plugin to strip Flow types and type imports/exports.
Basically I want a module that can use functions that are outside its scope.
I need this because my work will only provide a framework where the user will be able to put its own code in. Something like this
Simulation.jl
abstract AbstractType
function startSimulation(unknown::AbstractType)
doStuff(unknown)
end
MyModule.jl
module MyModule
include("Simulation.jl")
export AbstractType, startSimulation
end
SomeImplementation.jl
type ConcreteType <: AbstractType
variable::Int64
end
doStuff(me::ConcreteType)
me.variable
end
and finally Main.jl
# push!(LOAD_PATH, pwd()) # for local usage
using MyModule
include("SomeImplementation.jl")
startSimulation(ConcreteType(5))
Where Simulation.jl and MyModule.jl are written by me and SomeImplementation.jl and Main.jl are written by the user.
Now the above example does not work, because modules have their own namespace and even tho SomeImplementation.jl is imported in main at line 3, the interpreter will not see it in line 4 of Simulation.jl.
I can not import anything in MyModule.jl, because I can not know how the user will name his stuff or what extra libs he might even need.
Is there are way to do this with modules? Otherwise I will just not use modules.
The answer here is to create stubs for all the functions you want to call within MyModule as a required interface for the custom subtypes of AbstractType. That is, within MyModule, you'd have:
abstract AbstractType
doStuff(::AbstractType) = error("custom AbstractType objects must define a `doStuff` method)
function startSimulation(unknown::AbstractType)
doStuff(unknown)
end
Then the concrete implementations just need to specifically add their doStuff method to the function in MyModule by importing it or qualifying it:
MyModule.doStuff(me::ConcreteType)
me.variable
end
I need to use reflectable on a third party lib but it is not working.
Consider this scenario:
Library A has the reflector declaration:
class Reflector extends Reflectable {
const Reflector()
: super(invokingCapability,
typeRelationsCapability,
metadataCapability,
superclassQuantifyCapability,
reflectedTypeCapability);
}
const Reflector reflector = const Reflector();
Library B has the classes that are annotated with the reflector:
import 'package:library_a/library_a.dart' show reflector;
#reflector
class whateverz {}
Now the application C needs to use reflection on whateverz class that is within library B.
My problem is that the reflectable lib can't see the whateverz class annotated. The build warns "reflector.dart: This reflector does not match anything"
And if I do "print(reflector.annotatedClasses);" it prints [] within the console.
Is this possible? To annotate the classes on a third party lib that I will end up using in an application with reflection?
If yes, what am I doing wrong?
I suspect that the transformation isn't being performed on the correct main file.
The transformer is capable of looking up any declaration in your program, so if there is a library in your program which is importing library B (and hence also library A) then the transformer should certainly be able to generate a mirror for class whateverz, and you should find that mirror in reflector.annotatedClasses.
But the set of files taken into account during transformation is the transitive closure of the imports from your entry point (that is, the relevant element in the entry_points specified in your pubspec.yaml), so if you specify an entry point which is not the actual main file then the transformer may get to work with a smaller (or just different) set of libraries. For instance, if you use library A as the entry point then the transformer won't know that library B exists (assuming that library A doesn't directly or indirectly import library B), so the transformer won't discover any declarations in library B and you won't get the corresponding mirrors.
If you are working on a library that other developers will import and use, you need to tell them to include the reflectable transformer in their pubspec.yaml and add an element to the entry_points (or check that they are using a wildcard that already matches all the desired entry points).
You can check out three_files_test.dart to see a tiny example where a reflector in one file is used to annotate classes in different files, and you can check out meta_reflectors_test.dart to see how you can decouple reflectors, target classes, and other elements even more (e.g., by using GlobalQuantifyCapability to associate a certain reflector with a certain target class without editing the file that contains the target class).