I'm using Babel with default es2015 preset to convert ES6 JS code. Since I'm working in another project with TypeScript, I've come to appreciate the publi/private annotation on methods.
I'd like to use the same annotation in JS code. Even if it won't actually make methods on the exported object private, I find it useful to know quickly if a method is used by other classes, or not.
Is there a Babel plugin or other means to strip away all public/private declarations, so I can use it in my code? even without namespace checking that would still be very helpful.
There is a current proposal for "Private Fields" that is in the process of being implemented, but it not part of Babel yet. In the next month or two I'd expect it to be available.
Related
Is everything in ES6 part of module.
eg. if I write in a file.
function simpleFunc(){
console.log("test")
}
Is this function not available to code in other places. In regular javascript , this function can also be executed from within html script.
What is the whole concept of modules. I understand polluting global namespace is a bad practice , but when we export a function or const, is it just an approach to avoid polluting global namespace. Can a developer still write var a= 10 in a js file and waste all the efforts of maintaining modules. I suppose this would still be possible because es6 is supposed to be backwards compatible with js.
Simply my question boils down to: Is a js file different when the language is ES6.
Not sure why no-one has answered this question yet, it's a simple answer, so I will answer it in case anyone else stumbles onto it:
Javascript is javascript.
ES5 practices still apply to ES6 in terms of script placement. Modularization allows you to import code from one script to another - this can help you keep large applications maintainable as well as many other structural benefits.
Additionally you are right about not polluting the global namespace - modules are also namespace containers, which protects the global namespace.
Here's a quote from a good (full) explanation to the importance of modules:
Modularization is the basic necessity for any software development. Breaking things into smaller pieces of functionality gives us the power to reuse the code. Modules are also containers for the namespaces.
I have a question to ask regarding checkstyle.
It seems that the checkstyle api accepts both module name,
ConstantName and ConstantNameCheck (ConstantName with Check concatenated) for the configuration file, checkstyle.xml.
I would like to ask why is there a double standard here even though documentations on http://checkstyle.sourceforge.net/ only promotes ConstantName module and what is the difference between using either of them? Will either one of them gets deprecated in future?
Thanks!
Behind the scenes, the ConstantName check is implemented by a Java class called
com.puppycrawl.tools.checkstyle.checks.naming.ConstantNameCheck.
You could actually refer to the module in checkstyle.xml by this so-called "fully qualified" name. The other notations are shorthand offered by Checkstyle for convenience. ConstantNameCheck is the simple name of the implementing Java class, and ConstantName is still shorter. Checkstyle will try all three variants when looking for the module in your checkstyle.xml. So, there is no difference between these notations.
The recommended way is to use the most concise form, ConstantName, but as far as I know, none of the other forms is going to get deprecated any time soon.
For an in-browser application written in ceylon-js it would be desirable to reduce the size of the ceylon.language-1.2.0.js file to only that what is actually needed.
This question was answered already.
How to use ceylon js (also with google closure compiler)
But the given solution involves manually editing javascript code resulting from compilation. This is not desirable since a compiler should produce code that hasn´t to be edited manually after compilation (abstraction).
And it is not clear to me if google closure compiler can cope with the ceylon flavour of it in a reliable way.
Is it instead a solution to copy ceylon.language source in ceylon into the project and import only those parts of ceylon.language into the project that are required by it? Then compile to javascript. And then leave away ceylon.language-1.2.0.js at all from the client / in-browser application.
Now my questions:
What parts are needed in the most simple browser application? I think of something like Array(String) and the like.
Has that solution a chance to work absolutely reliable?
Will there be a better solution coming from the authors of ceylon that make this attempt obsolete?
The compilation of the language module to JS is a tricky process, because of the native stuff involved and because there are a couple of declarations that have to be in a certain order for things to work.
Minification is still pending, we are going to do it but it's not the highest priority right now, and we have to determine the best way to solve this problem; one option that has been discussed is to have a version of the language module without any metamodel info, for example.
there is a trivial sample gist of using clojurescript with Sencha. I thought clojurescript was designed with first-class interop with javascript libraries in mind, but the more I read the more it seems that only Google Closure is a first class citizen to clojurescript, and interop with other javascript frameworks isn't important to them.
i see no reason why it can't work, am i missing something? i don't want to be 2 or 3 weeks into a prototype before giving up due to problems i can't forsee.
You can use any external JavaScript library. The main issue - if the library doesn't provide an externs.js, then you'll have trouble compiling your ClojureScript with the external library under advanced compilation. That may or may not matter for your use case.
I'd like to know what is the most efficient way of handling properties in Scala. I'm tired of having gazillion property files, xml files and other type of configuration files in Java and wonder if there's "best practice" to handle those someway more efficient in Scala?
Why would you have a gazillion property files?
I'm still using the Apache commons Digester, which works perfectly well in Scala. It's basically a very easy way of making a user-defined XML document map to method calls on a user-defined configurator class. I find it extremely useful when I want to parse some configuration data (as opposed to application properties).
For application properties, you might either use a dependency injection framework (like Spring) or just plain old property files. I'd also be interested to see if Scala offers anything on top of this, though.
EDIT: Typesafe config gives you a simple and powerful solution for configuration - https://github.com/typesafehub/config
ORIGINAL (possibly not very useful):
Quoting from "Programming in Scala":
"In Scala, you can configure via Scala code itself."
Scala's runtime linking allows for classes to be swapped at runtime and the general philosophy of these languages tends to favour convention over configuration. If you don't want to deal with gazillion property files, just don't have them.
Check out Configgy which looks like a neat little library. It includes nesting and change-notification. It also include a logging library.
Unfortunately, it didn't compile for me on the Mac instances I tried. Let us know if you have better luck and what you think...
Update: solved Mac compilation problems. See this post.