The only way I know to realize that a method or property access is missing an externs declaration is by using advanced mode compilation and then testing the result very carefully. Is there a better way?
I have two general rules to handle this issue. Most of the problems should be avoided by applying these rules.
Generate externs.js using generator solve the issues caused by external libraries
Use aget, aset to interact with non-clojurescript js object. Use .-property in clojurescript managed js object.
http://squirrel.pl/blog/2013/03/28/two-ways-to-access-properties-in-clojurescript/
Some Generators are exists.
http://michaelmclellan.me/javascript-externs-generator/
In cases, you need more information
https://github.com/cljsjs/packages/wiki/Creating-Externs
Related
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.
I've seen a lot of code in Sitecore where Assert.IsNull is used before any logic;
e.g.
Database database = Factory.GetDatabase(itemUri.DatabaseName);
Assert.IsNotNull(database, itemUri.DatabaseName);
return database.GetItem(attribute);
Could someone help me understand why I would use this?
This topic isn't really specific to Sitecore, even though in this case the assert methods are within the Sitecore library.
In general, assertions are used to ensure your code is correct during development, and exception handling makes sure your code copes in unpredictable circumstances.
Take a look at these SO questions for some very good explanations.
When to use an assertion and when to use an exception
When to use assert() and when to use try catch?
Here's an article specifically about the use of Sitecore assertions:
http://briancaos.wordpress.com/2012/01/20/sitecore-diagnostics-assert-statements/
Especially about the "SA1126: PrefixCallsCorrectly" rule which tells us to use "this." prefix for instance members.
Should I follow these rules in the Razor syntax?
Example:
<span>Name: #this.Model.Name</span>
Or:
<span>#this.Html.DisplayFor(m => m.Name)</span>
You may notice that the "this." is ineffective here (I'm agree). I want to follow a rule which is applicable for all my everyday codes.
And doesn't StyleCop check the Razor files?
Well, the usage of the "this" prefix is kind of a personal (which can be argumented) choice.
You can find an interesting discussion on this point here
Why does StyleCop recommend prefixing method or property calls with "this"?
By the way, Resharper, for example, has the inverse rule by default (remove "useless" this - meaning useless for the compiler).
But frankly, in a View, I think it's more noise than help.
Other point : use HtmlHelpers like #Html.DisplayTextFor(m => m.Name) in your case, as they're strongly typed, linked to model, take care of null values, etc.
Should I follow these rules in the Razor syntax?
If you have decided that it's worthwhile adding the "this" in your .cs files, why wouldn't you want to apply it to C# code elsewhere, such as embedded in a Razor view file? What if you were to have multiple lines of C# code in a #{ } block? Would the "this" start to seem more useful? (The issue of whether "this" is generally worthwhile is not particularly relevant here since you have presumably already standardized on using it.)
And doesn't StyleCop check the Razor files?
Nope, StyleCop does not check Razor files. The only parser currently included with StyleCop is a C# parser, which only examines files with a ".cs" extension.
I've been learning a fair bit of C# lately and noticed that the <> syntax is used a lot, eg:
Content.Load<AssetType>("asset name");
The only place I've seen this used in AS3 is when using Vectors:
var enemies:Vector.<Enemy> = new Vector.<Enemy>();
Can I implement use of this syntax myself somehow in ActionScript 3? For example, I may want my own method similar to Content.Load().
The syntax you're referring to is called generics, and Vector is the only way they can currently be used in AS3.
Here is a link to a related question about AS3's generics, why you can't create your own.
Hope this helps!
The only other place where the angled braces are used (as far as I know) is for declaring inline XML:
var myXML:XML = <rootNode><dataNode>What's up?</dataNode></rootNode>;
Which is horrible programming practice. I don't believe there is any way to extend AS3 in the manner you describe, as it is only possible to create class extensions, not entirely new language syntax.
As far as I know, the Realaxy editor provides generics through a language extension. The dev talks about it here (see the comments)
The only problem is that it ties you to the editor.
That said, you could also probably fake it through reflection, or just doing your own runtime checking. Not a perfect solution though
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.