I'd like to get a certain value from an environment variable in my Kotlin app, but I can't find anything about reading environment variables in the core libraries documentation.
I'd expect it to be under kotlin.system but there's really not that much there.
It is really easy to get a environment value if it exists or a default value by using the elvis operator in kotlin:
var envVar: String = System.getenv("varname") ?: "default_value"
You could always go down this approach:
val envVar : String? = System.getenv("varname")
Though, to be fair, this doesn't feel particularly idiomatic, as you're leveraging Java's System class, not Kotlin's.
And if you want to handle env var which do exists but is empty:
val myEnv = (System.getenv("MY_ENV") ?: "").ifEmpty { "default_value" }
(see edit history for previos versions)
You can use the kotlin extension Konfig
Konfig - A Type Safe Configuration API for Kotlin
Konfig provides an extensible, type-safe API for configuration properties gathered from multiple sources — built in resources, system properties, property files, environment variables, command-line arguments, etc.
For example: Key("http.port", intType)
Related
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
According to the GTK API reference, the "license-type" property of GtkAboutDialog is only present in GTK >= 3.0. For compatibility, my code currently checks the GTK version before setting the "license-type" property:
-- This is Lua code binding to GTK via lgi
local dialog = Gtk.AboutDialog {
title = "About Me",
-- ...,
}
if Gtk.check_version(3,0,0) == nil then
dialog.license_type = Gtk.License.MIT_X11
end
Instead of doing this, is there a way to directly ask GTK if a widget supports a certain property? I think the code would be more self-documenting and less bug prone if I could write something that looks like
if supports_property(dialog, "license-type") then
dialog.license_type = Gtk.License.MIT_X11
end
Since this question is really about the GTK API, I'm OK with answers in any programming language. Although the examples are in Lua, I assume a similar problem should show up in other dynamic-language bindings or even in C, assuming that there is a way to set properties by name without going through the set_license_type accessor function.
You don't need to use the _property field like you are doing in your currently accepted answer since lgi finds all names in the type categories tables directly. Additionally, it is also possible to get type of an instance using _type accessor. So I'd recommend following solution:
if dialog._type.license_type then
dialog.license_type = Gtk.License.MIT_X11
end
You can use the g_object_class_find_property() function to see if a property exists.
Note that this function takes a GObjectClass, not the GObject instance. All GObject classes come in these class-instance pairs, with the class structure used for shared things like vtable methods. To get the GObjectClass associated with an object instance, in C, you can use the G_OBJECT_GET_CLASS() macro. (If you want to do this in Lua, and if Lua can't call C macros like that, you'll have to trace the definition of G_OBJECT_GET_CLASS().)
In lgi, a class's properties are present in its _property field:
if Gtk.AboutDialog._property.license_type then
dialog.license_type = Gtk.License.MIT_X11
end
If for some reasons you need to know if a property is present without instantiating it, you can go with #andlabs idea in this way:
local lgi = require'lgi'
local Gtk = lgi.require'Gtk'
local class = Gtk.AboutDialogClass()
-- Prints yes
if class:find_property('license') then print('yes') end
-- Does not print anything
if class:find_property('unknown') then print('yes') end
We have small set of environment variables exposed to control our application behavior. Application code is in java. (Environment variables may be evil, but the have a purpose in this special case)
What is the best way to unit test this? How can I create environment variables, set it to different values and call the tests repeatedly?
Current solution is to use env element in junit tasks . For example below
<env key="BASE_PLUGINS_FOLDER" value="c:/temp"/>
code sets environment variable for the test. (This works only when fork mode is set to true)
This means I have to create multiple test sections in ant build file and corresponding test else where. This could become unmanageable pretty fast.
I feel there could be a better way, that is fully a junit-java code. Not sure how.
You should encapsulate how you retrieve these variables. Not only will it allow you to change the way you pass them around (env variable, system properties, configuration file, etc...) but it will also more testable.
Then you can define two different implementations: one that actually reads the environment (which you use in production) and one where you can specify these values yourself in Java (which you use in your tests).
Here is a hack given by my friend..
Class<?> processEnvironmentClass = Class.forName("java.lang.ProcessEnvironment");
Field theEnvironmentField = processEnvironmentClass.getDeclaredField("theCaseInsensitiveEnvironment");
theEnvironmentField.setAccessible(true);
#SuppressWarnings({"unchecked"}) // this will be a Map or the test will fail if Java internals are changed
Map<String, String> env = (Map<String, String>) theEnvironmentField.get(null);
env.put(name, val);
// now System.getenv will return what we want
//noinspection CallToSystemGetenv
assertEquals("Problems setting up environment variable for test: " + name, val, System.getenv(name));
I fear this is a useless, frustrating answer... but consider redesigning the app to allow overriding the environment variables.
All access to them would need to be funneled through one place, which would also look for your choice of config mechanism -
-D,
or property file,
or property file pointed at by -D,
or runtime-created config object passed by test setup,
or smoke signals,
or ...
This can be solved using System Stubs (https://github.com/webcompere/system-stubs) in JUnit 4 and JUnit 5:
JUnit 4:
#Rule
public EnvironmentVariablesRule env = new EnvironmentVariablesRule("BASE_PLUGINS_FOLDER", "/tmp/something");
#Test
public void test() {
// variable is set here
}
Or in JUnit 5:
#ExtendWith(SystemStubsExtension.class)
class SomeTest {
#SystemStub
private EnvironmentVariables env = new EnvironmentVariables("BASE_PLUGINS_FOLDER", "/tmp/something");
#Test
void envSetHere() {
// environment variable is set
}
}
How do I access environment variables in Vala? (as above) it seems simple, but I can't find how g_getenv() is mapped into Vala.
The answer lies in the bindings file. Vala uses bindings (in .vapi files) for binding its constructs to the C language. In this case you can grep through glib-2.0.vapi (on my system that is in /usr/share/vala-0.10/vapi), and you'll see that it is bound as:
unowned string? GLib.Environment.get_variable(string name)
It can be quite useful to have the location of the core VAPI files handy, because if you know the C name of a function you can just grep for it.
In Groovy types are optional so you can use either:
String foo = "foo"
foo.noSuchMethod()
or
def foo = "foo"
foo.noSuchMethod()
I assumed that the first example would generate a compile-time error, whereas the second would only fail at runtime. However, this doesn't appear to be the case. In my experience, a compile-time error is generated in neither case.
Am I right in assuming then that the only benefit of declaring the type of a reference is as a form of documentation, i.e. to communicate intentions to other programmers. For example, if I write a method such as:
def capitalize(String arg) {
return arg.toUpperCase()
}
This communicates the type of arguments that should be passed to the function much more effectively than:
def capitalize(def arg) {
return arg.toUpperCase()
}
Does the Groovy compiler perform any type-checking when types are specified?
Thanks,
Don
[Edit] Newer versions of Groovy do allow for compile-time static type checking. Code that uses this annotation IS faster than regular run-time Groovy, as many of the dynamic checks are skipped.
As Cesar said, type checking is a run-time process, one of the major reasons that Groovy is slower than Java (not that that's really bad).
You can see why this is, right? Given the dynamic nature of Groovy, it's near-impossible to tell if String has been extended somewhere else in your code to contain a method noSuchMethod(). The same goes for member type-checking, as it's entirely possible to remove a member of one type, and add a member of another type with the same name later in code. It's probably not common, but very possible.
The question is, how much type checking do you really need? You're calling the method, you really should know what arguments it takes, or if the method actually exists. Using compile-time checking to save you the time of looking it up isn't a core usefulness of the compiler.
In Groovy, type checking is done dynamically at runtime. The benefits of variables with type is that you can be sure that it contains the value you expect them to have, otherwise you get a runtime exception that you can catch and do whatever you need to do to handle the exception.
Compile time-checking in Groovy is close to impossible for types. Your example of
String foo = "foo"
foo.noSuchMethod()
Would work beautifully given that previously an instruction was executed along the lines of
String.metaClass.noSuchMethod { -> println "Yes there is such a method"}
One reason you might specify a type is to allow an IDE to help you.
def foo
foo.[ctrl-space]
... won't help you very much
List foo
foo.[ctrl-space]
... might (depending on the IDE) give you a choice of List's methods. Of course, a method that's not one of the choices might be a valid one to use, for the reasons given in other answers.
There are other automated software maintenance operations that benefit from clues about types. For example, refactoring.