When I import a library in elm, will importing only specific functions be more efficient than exposing everything ?
For example, when I import the Html module I usually just expose everything
import Html exposing (..)
This is convenient so as i keep writing I don't have to keep modifying the definition to add more Html tags, but is it efficient ? Will the compiler realize I don't need the entire library in my source code or will it import it all ?
I don't think there is a performance advantage in importing exactly the functions that you want to use. As farmio mentioned, before 0.19 the whole module is imported anyway and after 0.19 you can pass --optimize to eliminate dead code.
However, I strongly recommend against importing all the functions exposed by a module because it makes code very hard to read. Imagine this case:
import Html exposing (..)
import Svg exposing (..)
import Html.Attributes exposing (..)
import Svg.Attributes exposing (..)
We have pulled all the functions from those four modules into our own namespace, so everytime I read the name of a function which is not defined I have to guess where that function is coming from. The alternative is just exposing types but never functions:
import Html exposing (Html)
import Svg exposing (Svg)
import Html.Attributes as HAttr
import Svg.Attributes as SAttr
In this way, not once you will have to guess where the function is coming from.
Since elm 0.19 the compiler has function level dead code elimination. So your compiled App should be the same either way.
I'm not sure if exposing only used functions would shorten compile time tough.
https://elm-lang.org/blog/small-assets-without-the-headache
Related
I want to make my custom inline function in .kt file using checkRadix function already implemented by Kotlin.
But I cannot import it. How can I import and use it?
I tried
import kotlin.jvm.JvmMultifileClass.*
kotlin.jvm.JvmMultifileClass.checkRadix(radix)
But I can't compile and there is no recommended resolution by IDE.
That function is marked as internal, which means it's only available within that module — i.e. within the Kotlin stdlib, not to your code.
I don't know why it's marked like that; maybe JetBrains consider it an implementation detail. But they clearly don't want it being used by any other code.
(Of course, it wouldn't be hard to reimplement yourself.)
I have seen a couple of examples using either syntax of:
import Browser exposing (..)
or
import Browser
Are these equivalent? Does the second syntax implicitly exposes everything?
No those are not equivalent.
import Browser
is a qualified import where
import Browser exposing (..)
is an unqualified import.
When using qualified imports you still have to use the fully qualified names of the imported functions and types. With unqualified imports those become available without having to fully qualify them.
See Elm Modules and Imports for a good introduction.
As the stores are files, I’m inclined to make them snake_case.js so they’d become snake_case in Vue.
However, snake case seems not to be used much in Vue, so should instead the files be camelCase.js so they can be refered to as camelCase.
I appreciate that Stack Overflow is not really for opinions, so I am seeking a guide or reference that notes the best way to do this.
In the official Vue.js style guide, they say
"Within JavaScript, camelCase is more natural. Within HTML, kebab-case
is."
In my opinion it seems much more elegant when it comes to listing and reading them inside the code using camelCase. In my organization we always use camel in the case of stores as follows:
import Vue from 'vue'
import Vuex from 'vuex'
import filtersStore from './modules/filters'
import langStore from './modules/lang'
import modulesStore from './modules/modules'
import utilStore from './modules/util'
import productsStore from './modules/products'
import catalogueStore from './modules/catalogue'
import reportsStore from './modules/reports'
import featuresStore from './modules/features'
import feedDataStore from './modules/feedData'
Anyway, I understand that both forms are considered good practice.
_ EDITED _
All the above is in /store/index.js, which is exported with:
export default new Vuex.Store({
mutations,
modules: {
filtersStore,
langStore,
modulesStore,
utilStore,
productsStore,
catalogueStore,
reportsStore,
featuresStore,
feedDataStore
}
})
and globally imported un main vue's app.js like:
import store from './store'
I have been dealing with kotlin multiplatform alot recently, and I totaly understand the nature of the development. Initially, I had my own expected Math class (in a common module) and I had actual classes in the JS and JVM environment.
Since I like to read the documentations, I found that the Math liblary has been added to the standard liblary since kotlin 1.2. this trouble me as I am using kotlin 1.2.51 and I get an error trying to access the class from kotlin.Math in my common module and any of my platform specific module.
What am I not geting? How do I get access to the kotlin.Math class in my common module?
The Math-class is deprecated and the deprecated-message contains:
Use top-level functions from kotlin.math package instead.
(see also https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.js/-math/index.html)
So somehow the answer of #mTak is right, even though it was not mentioned, that you should use the kotlin.math.*-import instead of your Math-class.
Alternatively, you can also import kotlin.math.max, etc. depending on which function you actually require.
The more I think of it: I don't know whether there ever was a Math-class in the jvm-variant of Kotlin (couldn't find anything regarding it) and so in a multiplatform project the Math-class-access probably should always have failed.
Import it like this: import kotlin.math.*
In the Kotlin standard library math functions are provided as top-level functions in the kotlin.math package.
Therefore you need to import that package and then you'll be able to use functions from it, like sin, sqrt and so on.
import kotlin.math.*
val sqrt2 = sqrt(2.0)
You can also import functions one by one, e.g. import kotlin.math.sqrt or even call them fully qualified val result = kotlin.math.sqrt(2.0)
After a while (I even feel stupid). I found that the kotlin.math library in kotlin common modules was already added. The only difference was, it had no the 'Math.' predecessor as I am normally used to.
So, Math.round(x: Float) was just round(x: Float)
Math.sin(x: Float) was just sin(x: Float)
I am working on some extensions for Rebol 3 (posix/fann/math).
To avoid global namespace pollution, I am exporting the functions with a simple prefix source identifier. For example: POSIX-FORK for fork, or POSIX-NANOSLEEP for nanosleep.
Is there any better approach or official Rebol naming convention?
That's a pretty standard naming convention for Rebol exports, though they should be lowercase in the code of course. The all uppercase thing is just a naming convention when referring to functions in chat clients or web sites that can't show code like this. You generally don't uppercase any words in Rebol code unless they are used for something else.
However, if you want to avoid global namespace pollution, declare your extension module with the options: [private] header. That will make it so the exports of your module are only imported by modules or scripts that request them explicitly with import or the needs header. This especially goes for modules or extensions that export low-level C-like APIs, which are best only imported by the modules that implement the high-level wrappers. It's good to remember that the module part of the extension is a full Rebol module, and it is often best to put your high-level wrapper code there and not export the C-like functions at all, keeping them for internal use.
An additional trick is that when you are exporting constants or enum values, it is best to put them in an object in your module and export the object instead. That way you don't export to the global namespace and you can protect the words from modification.
Another trick is to not export stuff at all and have people import your module using the import function. Unless you mark your module's words as hidden they will still be available even if they're not exported. This is a little inconvenient in most cases though, so it's better to use a private module instead. You can also export your high-level API and not export your low-level API, so the low-level API is available to import if someone wants to use it.
Check here for a more thorough answer about how modules and extensions are used: How are words bound within a Rebol module?