I have imported an other proto which having different package name than mine. For usage of messages from other package, have accessed that message with package name.
For Example :
other.proto
package muthu.other;
message Other{
required float val = 1;
}
myproto.proto
package muthu.test;
import "other.proto";
message MyProto{
required string str = 1;
optional muthu.other.Other.val = 2;
}
Is there a way to use val of muthu.other package directly like optional val = 2; instead of using muthu.other.Other.val ?
Couldn't find any help document regarding this. Help me out.
If the package name is same then you can omit the package name from the field declaration but otherwise there is no other way. if you can include muthu.test in the same package by specifying "package muthu.other" then it is allowed.
From Google documentation of protobuf:
You can add an optional package specifier to a .proto file to prevent name clashes between protocol message types.
package foo.bar;
message Open { ... }
You can then use the package specifier when defining fields of your message type:
message Foo {
...
required foo.bar.Open open = 1;
...
}
Related
Is it possible to include in *conf file another conf file?
Current implementation:
// db-writer.conf
writer: {
name="DatabaseWriter",
model="model1",
table-name="model1",
append=false,
create-table-file="sql/create_table_model1.sql",
source-file="abcd.csv"
}
Desired solution:
// model1.conf + others model2.conf, model3.conf..
table: {
name="model1",
table-name="model1",
create-table-file="../sql/create_table_model1.sql"
}
//db-writer.conf
import model1.conf <=== some import?
writer: {
name="DatabaseWriter",
model="model1", <=== some reference like this?
append=false,
source-file="abcd.csv"
}
Reason why I would like to have it like this is :
to reduce duplicated definitions
to pre-define user conf file which are rare modified
I guess it is not possible - if not do you have any suggestion how to separate configs & reuse them?
I'm using scala 2.12 lang and pureconfig 0.14 (can be updated to any newer)
Pureconfig uses HOCON (though some of the interpretation of things like durations differ). HOCON include is supported.
So assuming that you have model1.conf in your resources (e.g. src/main/resources), all you need in db-writer.conf is
include "model1"
HOCON-style overrides and concatenation are also supported:
writer: ${table} {
name = "DatabaseWriter"
model = "model1"
append = false
source-file = "abcd"
}
I have the following class in my code
abstract class DatabaseKey<T> implements Built<DatabaseKey<T>, DatabaseKeyBuilder<T>> {
DatabaseKey._();
factory DatabaseKey([void Function(DatabaseKeyBuilder<T>) updates]) = _$DatabaseKey<T>;
String get name;
}
Then, I define the following generic typedef function:
typedef ObserveDatabaseEntity = Observable<DatabaseEntity<T>> Function<T>(DatabaseKey<T> key);
But, when I try to use it as follows, the code has an error.
static ObserveConfigurationValue observe(
GetConfigurationState getState,
ObserveDatabaseEntity observeDatabaseEntity,
) {
assert(getState != null);
assert(observeDatabaseEntity != null);
return <KT>(ConfigKey<KT> key) {
return Observable.just(getState())
.flatMap((state) {
final dbKey = _databaseKeyFromConfig<KT>(key);
return observeDatabaseEntity(dbKey)
.map(_configValueFromDatabaseEntity);
});
}
}
DatabaseKey<T> _databaseKeyFromConfig<T>(ConfigKey<T> key) {
return DatabaseKey((build) => build
..name = key.value,
);
}
The error I am getting is:
The argument type DatabaseKey can't be assigned to the parameter DatabaseKey.
I see nothing wrong with this code or why it shouldn't work, but maybe my understanding of what can be written in Dart is wrong. What would be the correct way to write this, if possible at all?
EDIT#1:
Note:
The typedef ObserveDatabaseEntity is in one file
The static ObserveConfigurationValue observe(GetConfigurationState getState, ObserveDatabaseEntity observeDatabaseEntity) is is another file
From playing around, it seems that placing them in a single file, the error disappears.
Still, I believe that this should work in separate files as well,
This error looks like an import mismatch.
In dart, you can import file either through relative path or package.
import 'lib/some_file.dart'; //relative
import 'package:myapp/lib/some_file.dart'; //package
There's really no better way but once you choose one, you have to stick to it. If you don't (meaning you have imported a file using a package import and the same file elsewhere with a relative path) Dart will place them in two different namespaces and think they are two different classes.
Im learning about protobuf and am playing with alexeyxo/protobuf-swift.
Is there a way to cast protobuf Messages into the type they extend?
proto file:
message Command_Login {
extend SessionCommand {
optional Command_Login ext = 1001;
}
optional string user_name = 1;
optional string password = 2;
}
Here is the swiftcode:
let commandContainerBuilder = CommandContainer.Builder()
commandContainerBuilder.sessionCommand.append(commandLogin)
// sessionCommand is an array of SessionCommand (of which Command_Login extends)
Error:
Cannot convert value of type CommandLogin? to expected argument type SessionCommand
Sorry, you've misinterpreted extensions. I say "sorry" because this is probably my fault -- I designed the "extensions" feature, and unfortunately by using the word "extend" I confused a lot of people.
You see, extensions have nothing to do with inheritance. In your example, you are not declaring that Command_Login is any kind of subclass of SessionCommand. This is easier to understand if we shift the declarations around a bit:
message Command_Login {
optional string user_name = 1;
optional string password = 2;
}
extend SessionCommand {
optional Command_Login ext = 1001;
}
The above is completely valid and exactly equivalent to your code except for one difference: In your version, the extension's name is Command_Login.ext (because you declared it nested inside Command_Login), but in my version the name is just ext (in the global scope). Other than namespacing, they function the same.
What the extend clause actually does is declare a new field on SessionContext, where the type of that field is Command_Login. If you happen to place an extend clause inside of a message block, this only matters for namespacing purposes, much like declaring static members of a class in C++ or Java.
I am creating a library in typescript, which is spread across multiple files. I take all the classes and constants I have defines and import them into one module, which exports them all under one namespace. I have just defines an interface, and I wish to include it in the same namespace/module as all the other parts of my library. But apparently I can't.
Here's a simplified example:
/app.ts is the entry point of the application, all I do in it at the moment is include my library MyLib:
//app.ts
import myLib = require("lib/MyLib/MyLib"); // this works fine
/lib/MyLib/MyLib.ts is the file in which I import all of the things defined by MyLib, and export them together:
// lib/MyLib/MyLib.ts
import VehiclesImport = require("./transport/vehicles");
// error under VehiclesImport.IAutomobile, saying that VehiclesImport has no property IAutomobile
export var IAutomobile = VehiclesImport.IAutomobile;
export var Car = VehiclesImport.Car;
In /lib/MyLib/transport/vehicles.ts, I define several classes and interfaces of vehicles, here, I'll just show IAutomobile and Car:
// lib/MyLib/transport/vehicles.ts
export interface IAutomobile {
weight: number
}
export class Car implements IAutomobile {
weight = 3000
}
I have tried creating a class truck in MyLib.ts, which properly implements IAutomobile, and that works fine, without any error messages. The problem only seems to arise when I want to access IAutomobile outside of an 'implements' statement.
I apologize if this seems like a 'code dump', but in my opinion, this is a serious problem that I cannot access my interfaces except in a class declaration. I have searched Google for the past two hours and found nothing on the subject. Thanks for any help you can give me!
Edit: I understand that typescript interfaces are not part of the compiled javascript code, but that should not stop me from manipulating them within typescript.
Use the import keyword to bring in something into the type declaration space (as opposed to var which brings it into the variable declaration space).
This is demonstrated below. a.ts:
export interface A {
val: number;
}
To re-export this from another file b.ts:
import a = require('./a');
export import B = a.A; // Important use of import
Sample usage in some other file c.ts:
import b = require('./b');
var foo: b.B;
foo.val = 123;
interface C extends b.B {
val2:number;
}
var bar: C;
bar.val2 = 456;
The example rewritten following TS language specification:
a.ts:
export interface A {
val: number;
}
To re-export this from another file b.ts:
export {A} from './a'
Usage in some other file c.ts:
import {A} from './b'
var foo: A = {val: 2};
foo.val = 123;
interface C extends A {
val2:number;
}
var bar: C = {val: 1, val2: 3};
bar.val2 = 456;
Types can't be assigned to variables, they exist in different "declaration spaces". Classes can be assigned to variables, because they contribute their names to the type declaration space as well as defining the class objects. Interfaces only contribute to the types declaration space, so can't be referenced as values.
The language is a bit verbose, but this is spelt out in detail in section 2.3 of the language spec
foo.ts
export interface ITest {
...
}
bar.ts
import * as foo from "./foo";
export type ITest = foo.ITest;
This works to re-export types/interfaces
import type { MyInterface, MyType } from './randomModule';
export { MyInterface, MyType }
The key is the surrounding braces in the export statement. Works in TypeScript 4.7.4. Reference.
In TypeScript 3.9.6, this worked for me:
import { Foo as FooType } from './some-path';
export type Foo = FooType;
Darts Mirrors are for me currently poorly documented and very difficult to experiment with - they behave differently in code than from within the console.
for my own use, I would love to be able to treat classes (Types) as a trees, with a node being something like:
class Node {
type ... <== Type itself
name ... <== name of current class
super ... <== super of this class, eg, extends super
mixins ... <== mixins used to build this Type
extendChildren ... <== Types for which this type is super
mixinChildren ... <== Types for which this type is a mixin
}
for the life of me, I cannot get something this basic out of current Mirrors. hoping that somebody smarter than me has given it a shot!!
Below is a simple example which prints the name of the superclass and the name of Foo's members.
Note that the API uses Symbols, not strings. These are required so that dart2js can minify code that uses mirrors, they're a bit of a pain, but they mean that your code will run cross browser, and be compact.
To convert between symbols and strings see MirrorSystem.getName() and MirrorSystem.getSymbol() (Actually I believe you can just use new Symbol('foo') now).
Also note a new feature was recently added giving a special literal syntax for symbols. Up until recently you needed to type const Symbol('foo'), now just #foo, you may see a mix of old an new when looking at examples.
See this article for more information about mirrors.
Warning - probably a few typos in the example.
import 'dart:mirrors';
class Bob {
}
class Foo extends Bob {
String bar = 'jim';
}
main() {
var classMirror = reflectClass(Foo);
print(MirrorSystem.getName(classMirror.superClass.simpleName));
classMirror.declarations.values.forEach((d) => print(MirrorSystem.getName(d.simpleName)));
}
Update: Based on what Alan said below (Also untested):
Example source:
library foo;
class B extends A {
}
class A {
}
Definition:
List<ClassMirror> findSubClasses(Symbol libraryName, ClassMirror superClass) =>
currentMirrorSystem().findLibrary(libraryName).declarations.values
.where((d) => d is ClassMirror
&& d.superClass.simpleName == superClass.simpleName);
Usage:
var cm = reflectClass(A);
var subclasses = findSubClasses(#foo, cm);
There is a #MirrorsUsed attribute that you may want to experiment with if you're interested on compiling to js. It's still experimental so expect this to change.