Can you have a custom attribute in yang schema? - parsing

I wanted to know if we could define a custom field or attribute in one of the elements leaf,list etc. For eg: Is this possible? How can we define such fields if its possible.
model Animal{
leaf amphibian{
type String;
custom "Frog"; // Custom field which has a value "Frog"
}
}

An "attribute" as in a "new YANG keyword"
If by "attribute" you are referring to a new YANG keyword, that has special meaning to you, then yes. YANG supports extensions. From RFC6020:
The "extension" statement allows the definition of new statements
within the YANG language. This new statement definition can be
imported and used by other modules.
The statement's argument is an identifier that is the new keyword for
the extension and must be followed by a block of substatements that
holds detailed extension information. The purpose of the "extension"
statement is to define a keyword, so that it can be imported and used
by other modules.
The extension can be used like a normal YANG statement, with the
statement name followed by an argument if one is defined by the
extension, and an optional block of substatements. The statement's
name is created by combining the prefix of the module in which the
extension was defined, a colon (":"), and the extension's keyword,
with no interleaving whitespace.
extension custom {
argument object;
description "A new YANG keyword that carries special semantics.";
}
prefix:custom "Frog"; // usage of an extension
The argument keyword in the above example is an optional substatement to an extension keyword and is used to indicate that the new keyword takes (mandates) an argument (a string, such as "Frog").
The "argument" statement, which is optional, takes as an argument a
string that is the name of the argument to the keyword. If no
argument statement is present, the keyword expects no argument when
it is used.
7.17.2
Why do you need a named argument for the new keyword? YANG may be mapped to YIN, the alternative syntax expressed as XML and that is where this name becomes important.
The argument's name is used in the YIN mapping, where it is used as
an XML attribute or element name, depending on the argument's "yin-
element" statement.
7.17.2
You cannot restrict the value space of this argument per se - a YANG compiler will always recognize it as a string. But there is nothing stopping you from requiring implementations to expect certain values - you are defining the meaning of the new keyword after all.
extension custom {
argument value;
description
"The value of "custom" statement's argument MUST be an integer
in the range from 1 to 5.";
}
prefix:custom 3;
Description statements contain normative text, so if your extension contains a description substatement, stating that "value of this statement's argument MUST be an integer", then an implementation will have to respect this text.
An "attribute" as in an "XML attribute" (or a JSON equivalent)
If you meant an "attribute" in instance documents (XML, JSON,...) modeled with YANG, then the answer is no - for the most part. Pure YANG does not support modeling attributes.
However, there is a published specification for a YANG extension that allows such attributes to be defined. You can read more about that here (RFC7952). The extension is called annotation and is used to define YANG metadata, additional information that augments data that may already be modeled with YANG. Here's an example:
module using-annotation {
namespace "org:example:using-annotation";
prefix "ua";
import ietf-yang-metadata {
prefix "md";
}
md:annotation my-annotation {
type string;
description "This is my annotation.";
}
container top {
leaf some-leaf {
type string;
}
}
}
This would be a valid XML instance according to the above model:
<ua:top xmlns:ua="org:example:using-annotation">
<ua:some-leaf ua:my-annotation="Yay!">foo</ua:some-leaf>
</ua:top>
It allows an XML attribute to become valid almost anywhere.
Reading RFC7952 may also be useful for learning how the extension statement actually works and how to properly define a YANG extension.

Related

Is "dynamic" a data type in Dart?

I have read that dynamic is a data type in Dart, but is it correct to call it a data type? it doesn't seems like a data type, it seems like it is a way to allow your variable to be of any data type.
In Dart, dynamic is a type. It belongs in the type hierarchy and is related to other types by the subtype relation.
It's a "top" type, which means that every type is a subtype of dynamic. (Including itself, because the "subtype" relation is reflexive - every type is considered a subtype of itself, and the term "proper subtype" is used when only talking about subtypes that are not also supertypes.)
Being a top type, it means any value can be assigned to a variable of type dynamic. So can they to any other top type, which mainly means Object?.
The difference between the two is that:
An expression with static type dynamic can be assigned to any type. That's obviously unsafe, so the runtime inserts a check, a so called "implicit downcast" which works just like doing as TargetType.
You can call any member on an expression with static type dynamic. That's obviously unsafe, so the runtime will throw if the object doesn't have such a member.
That kind of runtime checked unsafe behavior (not static type-checked) is the reason the type is named dynamic. Using dynamic is a way to turn off the static type system. Use with extreme care.
Whether you can call dynamic a "data type" depends on what you mean by "data type". The Dart language specification doesn't use the term "data type" about anything.
Yes. The specifications call it a type (https://www.ecma-international.org/publications-and-standards/standards/ecma-408/)
The type dynamic denotes the unknown type. If no static type
annotation has been provided the type system assumes the declaration
has the unknown type
Type dynamic has methods for every possible identifier and arity, with
every possible combination of named parameters. These methods all have
dynamic as their return type, and their formal parameters all have
type dynamic. Type dynamic has properties for every possible
identifier. These properties all have type dynamic

Dart generics not reified as per the docs

I'm trying to pass a type in order to make use of the type information, but that types doesn't appear to be pass through.
I went back to the docs to double check that Dart generics are in fact reified and according to the docs, they are:
I call hydrate on a response which morphs the content of response object:
response.hydrate<BoqVO>();
I'm expecting T to be of type BoqVO:
class Response {
...
void hydrate<T>() {
print(T.runtimeType); // always prints _Type
if (T is BoqVO) {
print("IF");
} else {
print("ELSE"); // always goes into ELSE block
}
}
...
}
... but it's not.
Replacing response.hydrate<BoqVO>(); with response.hydrate(new BoqVO()); and changing the method signature to
void hydrate(T t) {
works if i now use lowercase t, but one shouldn't have to instantiate the object in order for reified generics to be available.
Any ideas why Dart is doing this or what i'm missing for reified generics to work correctly?
PS: I'm not on Dart 2 yet, currently on Dart 1.24.3
As Günther Zöchbauer has said, the type parameter doesn't work in Dart 1.24.
The following explains what would happen if you tried the same code in Dart 2.0, where it would also not work, because it uses the type parameter incorrectly.
The code T.runtimeType treats T as an expression. When a type, including a type parameter, is used as an expression, it evaluates to an instance of the class Type. What you print is the runtime type of that Type object (where _Type is an internal platform implementation of Type).
To print the real type, just print(T) (that still converts T to a Type object, but one representing the type BoqVO and with a toString that includes the BoqVO name).
Likewise for T is BoqVO, you evaluate T to a Type object, and since Type doesn't implement BoqVO, that test is always false. There is no simple way to test if the type of a type parameter implements a specific other type, but you can hack around it as <T>[] is List<BoqVO>.
Generic collections were supported from the beginning and they got some type support, but generic methods were only experimental in Dart 1 and reified type parameters were only added in Dart 2 pre releases.

wagtail StreamField block name translation issue

What I found in docs is the following:
The parameter to StreamField is a list of (name, block_type) tuples. ‘name’ is used to identify the block type within templates and the internal JSON representation (and should follow standard Python conventions for variable names: lower-case and underscores, no spaces) and ‘block_type’ should be a block definition object as described below. (Alternatively, StreamField can be passed a single StreamBlock instance - see Structural block types.)
'name' will be displayed in wagtail admin interface as the name of block.
Now I want to translate the name of blocks in StreamField.
I tried to use gettext and ugettext_lazy to wrap the name.
If gettext is used, then the display text on admin interface will be language of "LANGUAGE_CODE" in 'settings/base.py'. User specified language preference in admin interface will not make a difference.
If ugettext_lazy is used and user specified language differs from LANGUAGE_CODE in 'settings/base.py', there will be keyerrors where key is the translated content.
Is there a way to translate the name properly?
All block types accept a label argument for the name to display in the admin; you should apply the translation function there.
from django.utils.translation import ugettext_lazy as _
class MyPage(Page):
body = StreamField([
('heading', blocks.CharBlock(label=_("Heading"))),
])

Can we have more than 2 words in the name of a Parameter in Swift?

I'm a beginner at Swift.I would like to know if we can have more than 2 words in the name of a Parameter?
Also, are Parameter Name and Argument Label only used when there are 2 words in the name? What if there is only one word? Would we still call the parameter used inside the function as Parameter Name and the same one used outside as Argument Label or we would just call it a Parameter or we would call them both ?
Thankyou :)
Extend answer of Sweeper and Lumialxk
here publicName is the label of argument and privateName is the actual argument.
Label of argument defines related to the argument but when you wanted to use argument then you have to use actual argument
Example: With label
Below you can see first and last are the labels.
Example2: w/o label
Below you can see not label for first but last is the label.
Note: You can use _ for the first argument only.
Hope above example clears you.
Programming languages don't really have the concept of "words". Only "identifiers" and "tokens" exist.
To declare a parameter, you need three identifiers:
publicParameterName privateParameterName: Type
where publicParameterName can be _.
You can't use more than 2 identifiers in parameter names because that's how the language is designed. The compiler sees the first identifier and treats it as the public parameter name and it sees the second identifier and treats it as the private one. Then it sees a third identifier just before the :, What is it gonna treat it as? It does not know! That's why you get an error when you try to use three identifiers.
You can obviously use more than 2 "English words" in parameter names. Just make sure there are no spaces between those words, otherwise it will be treated as two identifiers This is an example:
func foo(aVeryLongParameterNameWithNineEnglishWords: Any)
As you can see, I used just one identifier for the parameter name in the above example. You can do this. If you only have one identifier, that will be treated as both the public and private parameter name.
That's not two words. The first one is public name, second private. You should use Camel-Case for more words.
func funcName(publicName privateName: Int) {}
There can be 2 names corresponding to a parameter of the method in swift:
1. External name - name visible outside the method
2. Internal name - name visible inside the method
Example:
func funcName(externalName internalName: Int)
{
print("\(internalName)")
}
funcName(externalNamme: 3)
External name is optional, i.e. if you don't give any external name it will consider internal name as the external one.
Example:
func funcName(internalName: Int)
{
print("\(internalName)")
}
funcName(internalName: 3)
Also, if you don't want to give any name to the argument while calling, you can replace external name by an underscore(_).
Example:
func funcName(_ internalName: Int)
{
print("\(internalName)")
}
funcName(3)

Getting FS0035 => Construct is deprecated

In a fsyacc based project, I have this line:
type 'a cucomment = string
This is the full error description I'm getting:
CALast.fs(117,9): error FS0035: This construct is deprecated: This
type abbreviation has one or more declared type parameters that do not
appear in the type being abbreviated. Type abbreviations must use all
declared type parameters in the type being abbreviated. Consider
removing one or more type parameters, or use a concrete type
definition that wraps an underlying type, such as 'type C<'a> = C of
...'.
Any idea how to solve this?
F# no longer allows type aliases that add generic type parameters to a type without declaring a new type. If you want to define a generic type that wraps some other type, you have to use some constructor. For example, you can use single-case discriminated union:
type 'a Cucomment = CC of string
Unfortunately, this means that you'd have to change all code that uses the type to unwrap the value using pattern matching or by adding Value member to the type.
The only case where generic type aliases are allowed is when you declare a version of type with units of measure, which requires a special attribute. However, this is probably not going to work for you (because units behave quite differently):
[<MeasureAnnotatedAbbreviation>]
type 'a Cucomment = string
If this is in some code generated by fsyacc, then that's a bug in fsyacc that should be fixed (I think this was quite recent change). In that case, report it to fsbugs at microsoft dot com.

Resources