With gdbus codegen, a struct/object is defined as a complete type in the xml like below
<method name="GetInfo">
<arg direction="out" type="(sib)" name="info"/>
</method>
However, if the same struct is used at multiple places, repeating the type definition is a bit painful, especially when the signature changes later on.
<method name="GetInfoList">
<arg direction="out" type="a(sib)" name="info_list"/>
</method>
So, is there a way to define an alias or a something for structs that we don't have to maintain the same thing at multiple places? Oh, and using Qt bindings is not an option in this case unfortunately.
Regards,
So, is there a way to define an alias or a something for structs that we don't have to maintain the same thing at multiple places?
No, there is not. That’s one of the disadvantages of using gdbus-codegen. If you want to define a struct for each of the D-Bus types in your API, you need to implement your service/client manually, without gdbus-codegen, using functions like g_dbus_connection_register_object().
Related
For example, is there a way to call the constructor of File class to create an instance of it?
Generally it just depends on the thing you want. Some things like File you have to go through an API, for example to create a file object in a rule function, you would use ctx.actions.declare_file(filename)
See this for examples: https://docs.bazel.build/versions/master/skylark/lib/actions.html#declare_file
Other things you can create directly, like depset has depset(). See global functions here https://docs.bazel.build/versions/master/skylark/lib/skylark-overview.html
Should I give type when creating variable?
Any downside for just declaring the keyword "var"?
Any difference between these two?
var a ＝ 0;
int a ＝ 0;
Pros/Cons
ONGOING WORK
Best Practices
It's recommended to use var or final keyword, without specifying type annotation, and implicitly infer type for known local variables. Otherwise it's recommended to specify type annotations. As for dynamic keyword, it should be used very sparingly in specific use-cases, when you're doing manual type checking. For example print(myVariable is SomeType).
omit_local_variable_types Dart linter rule encourages omitting type annotation for known local variables. always_specify_types encourages specifying type annotations for cases that don't fall into the scope of the former linter rule.
1. Style guide for Flutter repo
1.1 avoid using var
All variables and arguments are typed; avoid "dynamic" or "Object" in
any case where you could figure out the actual type. Always specialize
generic types where possible. Explicitly type all list and map
literals.
This achieves two purposes: it verifies that the type that the
compiler would infer matches the type you expect, and it makes the
code self-documenting in the case where the type is not obvious (e.g.
when calling anything other than a constructor).
Always avoid "var". Use "dynamic" if you are being explicit that the
type is unknown, but prefer "Object" and casting, as using dynamic
disables all static checking.
2. Dart Lint Rules
2.1 omit_local_variable_types
CONSIDER omitting type annotations for local variables.
Usually, the types of local variables can be easily inferred, so it
isn't necessary to annotate them.
2.2 always_specify_types
DO specify type annotations.
Avoid var when specifying that a type is unknown and short-hands that
elide type annotations. Use dynamic if you are being explicit that the
type is unknown. Use Object if you are being explicit that you want an
object that implements == and hashCode.
References
You can refer to Style guide for Flutter repo, full list of Dart's Linter Supported Lint Rules, and Effective Dart's Style Guide.
Note, Style guide for Flutter repo is used among flutter community and takes precedence over LinterRules and Effective Dart's Style Guide especially within repo contributions. From what I've seen, Style guide for Flutter repo is more of a superset Style Guide that should honor Dart Linter rules.
There isn't any difference between the two statements you gave.
And I don't see any downside to only declare the keyword "var", unless that your code might become a bit more difficult to read. On the other side, specifying the type might become a bit redundant sometimes.
But this is really just a question of taste 😄
I advise you to pick between those two, and be consistent in your code.
If you choose to always specify the type, you can use always_specify_types in your file analysis_options.yaml :
https://dart-lang.github.io/linter/lints/always_specify_types.html
I have a very simple problem of DI, and wanted to know if there is a way to solve it using Ninject (or any other DI helper).
I have a Data Access interface that is implemented by several Data Sources providers, like DB, Sharepoint, CRM, etc.
I want to use Ninject to get a specific instance of the interface, based on a parameter that contains a code representing one of this implementations.
So far I know that I can do that by using named bindings , but I couldn't find a way to do the same by xml config file (Ninject.extensions.xml).
Ninject extensions xml provides a way to solve single mappings:
<module name="SomeModule">
<bind service="Game.IWeapon" to="Game.Sword"/>
<bind service="Game.IWarrior" toProvider="Game.SamuraiProvider"/>
</module>
I'd like to do a config like that, but using multiple mappings for the same interface, using a name, a code or the like.
TIA,
Milton
Just add a name property
<bind service="Game.IWeapon" to="Game.Sword" name="sword"/>
<bind service="Game.IWeapon" to="Game.Dagger" name="dagger"/>
i have two ant files
mainBuild.xml
subBuild.xml
subBuild.xml is imported in the mainBuild.xml. One of target from mainBuild depends on subBuild. I need to pass the argument to the dependent ant target. I dont want to use the <antcall> or the <ant> tags, as i need the some properties from the
You can define the arguments in the property files, and then read that property in ant like this.
<property file="build.start.properties"/>
All properties in the property file will be imported in ant, and will be available as ant properties, which you can use in both mainBuild.xml and subBuild.xml.
refer this for further reference
Macros are one way to have re-usable code in ant. You can call them with different argument. Re-using of targets (using property ) may not be desirable as the properties are immutable.
I'm writing three different web services in three wsdls. The services all share a common type of generic error message. The three services are defined in three different namespaces but I want the error message to be defined in a fourth namespace. Is there a way to "import" or "include" the message-type into the three wsdl-files?
Yes, that should be possible. Use the <import> element to import the shared WSDL, in the portType's operation, you can fully qualify the name of message, i.e. you need to bind the fourth namespace to a prefix (e.g. ns4) and then add a reference like this:
<portType name="MyPortType">
<operation name="MyOperation">
<input message="tns:myInput"/>
<output message="tns:myOutput"/>
<fault message="ns4:myFault"/>
</operation>
</portType>
See http://www.w3.org/TR/wsdl#_style for further reference about the import mechanism.