I'm trying to build a CLI. I choose to use 'yang' to do so. I'm new to it and can't find out how to import existing moduls. As exemple I found a module for ospf on github (https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1631/ietf-ospf.yang) and I would like to import it in my own moduls. Can this be done? how?
EDIT1:
module mininet {
/* name space */
namespace "http://tail-f.com/ns/example/mininet";
prefix mininet;
import ietf-ospf {
prefix ospf;
revision-date 2015-03-09
}
leaf area-id-type {
type yang:area-id-type;
}
}
So I tried to do it this way using Piotr Babij help. Unfortunately this isn't working. What do I need to change?
area-id-type is a typedef of ietf-ospf. The error I have is te following one:
mininet.yang:12:3: error: trailing garbage after module
mininet.yang:12:3: error: unterminated statement
You may import other modules in your own modules by using the import statement. It is described in both RFC 7950 for YANG 1.1 and in RFC 6020 for YANG 1.0. In YANG 1.1 you may import two different revisions of the same module. Other that that, the import statement works the same in both versions.
In practice the basic import looks like this:
module acme-system {
namespace "http://acme.example.com/system";
prefix "acme";
import ietf-yang-types {
prefix "yang";
revision-date 2013-07-15;
}
leaf acme-ip-address {
type yang:dotted-quad;
}
}
If you omit the optional revision-date statement then an undefined module revision is imported. So, in general, it is a good practive to use it.
The mandatory prefix statement lets you to refer to the things in the imported module. In the example the prefix of the imported ietf-yang-types module is yang and, thanks to that, it is clear that yang:dotted-quad refers to a type from that module. In your case you have set the prefix to ospf, so you should have ospf:area-id-type to refer to a type definition from that module. If you import multiple modules you need to ensure their prefixes are unique.
Additionally, you are importing the oldest available revision of the ietf-ospf module. I just hope that this is what you really want to do.
Anyway, once you import a module you are allowed to:
use any grouping and typedef defined at the top level in the imported module or its submodules.
use any extension, feature, and identity defined in the imported module or its submodules.
use any node in the imported module's schema tree in must, path, and when statements, or as the target node in augment and deviation statements.
In the above example the typedef dotted-quad from the ietf-yang-types is used in the acme-system module.
Related
Ran into some interesting behavior in the Swift REPL:
1> import var Glibc.M_PI
2> M_PI
$R0: Double = 3.1415926535897931
3> M_E
$R1: Double = 2.7182818284590451
4>
According to the language documentation, only the symbol M_PI should be available when I do this import!
Import Declaration
An import declaration lets you access symbols that are declared outside the current file. The basic form imports the entire module; it consists of the import keyword followed by a module name:
import module
Providing more detail limits which symbols are imported—you can specify a specific submodule or a specific declaration within a module or submodule. When this detailed form is used, only the imported symbol (and not the module that declares it) is made available in the current scope.
import [import kind] [module].[symbol name]
import [module].[submodule]
But instead, M_E, sqrt(), sin(), log(), and the kitchen sink are now running around in the scope. How do I prevent all those other symbols from getting imported?
Strangely, this only happens in the Swift console; compiled Swift code doesn’t do this.
In TypeScript, how do you "import *" from a file without creating any aliases?
E.g. I have a file "utils" with top-level exported functions and want to import all them without recreating the aliases for each function.
Something like this:
import * from "utils";
Is that possible?
You can't generate an automatic name, you have to give it a name that is local to your file. This is by design to give each file its own naming context.
// import the default export (something exported with "export default")
import Stuff from "./Stuff";
// import specific things only; aliases in this style are optional
import { ItemA as AliasA, ItemB as AliasB } from "./Stuff";
import { ItemA, ItemB } from "./Stuff";
// import everything at once, grouped under a common name
import * as Stuff from "./Stuff";
I ... want to import all them without recreating the aliases for each function.
It sounds like you'd want the third option from above.
but with this syntax creates an alias
I think the idea is that if you could just import everything while taking the names as they are defined, then you'd have naming collisions. The way this works, you're forced to choose a name for every import, leaving it up to the names you choose to avoid collisions rather than having the imports clobber each other.
I think you can do something similar, but only with .d.ts files. jquery.d.ts does it, but I'm not 100% solid on how it works. You can simply say:
// where the file is really Stuff.d.ts
import "./Stuff";
I think the idea is to create a "Utils" module, attach all the functions and/or classes to it, put export in front of them, then export that instead, such as
module Utils {
export function add(first:number, second:number):number {
return first+second
}
}
export = Utils
Though i haven't played around with the es6 module syntax in typescript yet, as it seems you're implying to use.
You're close it's:
import * as utils from 'utils';
No curly braces.
About import statement, google says that https://developers.google.com/protocol-buffers/docs/proto#services :
You can use definitions from other .proto files by importing them. To import another .proto's definitions, you add an import statement to the top of your file.
By default you can only use definitions from directly imported .proto files.
...Sounds great, but what about that :
1.proto :
message M1{
required string foo = 1;
}
2.proto :
import "1.proto";
message M2{
required M1 m_1 = 1;
}
3.proto :
import "2.proto";
message M3{
required M2 m_2 = 1;
}
So, When parsing 3.proto, M1 shouldn't be accessible because 1.proto is not imported publicly from 2.proto.
However, M2 should be, because it is directely imported from 3.proto...
Thus what about M2.m_1 ? how a compiler should generate classes ?
What the documentation means is that if you want to refer to M1 in a file, you must import 1.proto, and if you want to refer to M2 in a file, you must import 2.proto. You do not need to explicitly import implicit/transitive dependencies. It's perfectly fine to use M2 without importing 1.proto.
The compiler actually follows the transitive imports and reads all three files in order to generate code for 3.proto. Moreover, in C++, 3.pb2.h will #include "2.pb2.h" which will in turn #include "1.pb2.h". The rule is only a syntax rule.
Why have this rule? Well, consider if you could directly use M1 in 3.proto without explicitly importing 1.proto, just because you imported 2.proto which itself imports 1.proto. Now consider if, later on, the maintainer of 2.proto decided to remove the field m_1. Now 2.proto doesn't use M1, so the maintainer decides to remove the import of 1.proto. But now 3.proto is broken, because it was relying on the fact that 2.proto imported 1.proto!
This is a common problem with C++ includes. I didn't want to have the same problem in Protobufs, so I made the rule that you must explicitly import all of the files declaring the types that you explicitly use in your own file.
The following example fails because the definition for Stuff can't be found:
package com.example
import javax.script.ScriptEngineManager
object Driver5 extends App {
case class Stuff(s: String, d: Double)
val e = new ScriptEngineManager().getEngineByName("scala")
println(e.eval("""import Driver5.Stuff; Stuff("Hello", 3.14)"""))
}
I'm unable to find any import statement that allows me to use my own classes inside of the eval statement. Am I doing something wrong? How does one import classes to be used during eval?
EDIT: Clarified example code to elicit more direct answers.
The Scripting engine does not know the context. It surely can't access all the local variables and imports in the script, since they are not available in the classfiles. (Well, variable names may be optionally available as a debug information, but it is virtually impossible to use them for this purpose.)
I am not sure if there is a special API for that. Imports are different across various languages, so bringing an API that should fit them all can be difficult.
You should be able to add the imports to the eval-ed String. I am not sure if there is a better way to do this.
I'm using a utility library for dimensional analysis that i'd like to extend with my own units, and I'd like to be able to write
import my.util.units._
in files in my project. My thought was to define
package my.util
object units {
import squants._
[... other definitions ...]
}
and I expected import my.util.units._ to have the same effect as import squants._, plus the other definitions. But it seems importing units._ doesn't end up adding squants._ to the scope.
Is there a way to do this in scala?
We've dealt with this a little bit at work, and we've tried to resolve this a few ways. Here's an example of how we import rabbitmq types throughout scala-amqp:
package com.bostontechnologies
package object amqp {
type RabbitShutdownListener = com.rabbitmq.client.ShutdownListener
type RabbitConnection = com.rabbitmq.client.Connection
type RabbitChannel = com.rabbitmq.client.Channel
type RabbitConsumer = com.rabbitmq.client.Consumer
type RabbitAddress = com.rabbitmq.client.Address
...
}
So now when we import com.bostontechnologies.amqp._ we get access to the rabbitmq types that we've defined. I know it requires quite a bit of duplication, however we've found it to be somewhat useful, especially since it gives us granularity over type names.
Also, you don't need to use a package object, we mainly use it for convenience of automatically importing our types around a package. You could just use a normal object as well.
Imports are not transitive in Java or Scala. Probably the closest you are going to get to what you seek is to create an object (perhaps a package object) with a type definition for each type of interest.