How does Binding.scala compare to the concept described here?
Apart from the design descriptions one might compare their implementations of TodoMVC:
Binding.scala
Scala.Rx + ScalaTags
Edit: By now I compared them to scalajs-react. I think react has a better performance, since e.g. for lists it updates only changed elements of the lists in the DOM, not the whole list.
Related
I want to do similar to scalajs-bootstrap for my own css. But as per my knowledge it doesn't perform partial dom update like Binding.scala does. I know we can use Binding.scala and scalatags together base on this but partial dom will not happen. Is there any solution?
Binding.scala's examples contain Scala XML tags as a language to code DOM fragments. Can scalatags be used instead?
Binding.scala internally generates very sophisticated ScalaTags code. On the other hand, manually written naive ScalaTags code recreates entire DOM whenever the data changes.
Milad Khajavi created an example demonstrating the problem of the manually written ScalaTags code: https://gitter.im/ThoughtWorksInc/Binding.scala?at=581b6367eed0c3125f30d57b
ScalaTags is very convenient for simple application. However, since they are plain function calls that do not have any ability to partially update, ScalaTags is not a good choice for a complex interactive application if you need fine-grained update on DOM.
I used FEST-Assert and moved to AssertJ after it stopped development.
Recently I was pointed to Google repository with another assertions library Truth (http://google.github.io/truth/).
Reading the examples I can not find any advantage of start using it over AssertJ. So it is just matter of taste what to use. But maybe I missed the point, did I?
From one of their comments at GitHub:
The core difference is that the design of Truth includes two specific
areas of extensibility - that of a strategy for proposition failure -
such that a "subject" for Integers, or a subject for Strings can be
re-used in the context of completely different results for failure. A
notable example is the distinction between JUnit's use of
AssertionError and it's AssumptionViolationException. Truth lets you
use the same proposition classes for both.
The other area of flexibility is the ability to create new
assertion/proposition types and hook them in without declaring
possibly conflicting static methods to import. This can be for new
types (say, adding protobufs) or for new uses of existing types (say,
Strings that are treated as Uris). This is the assertAbout() feature.
Other than that, Truth is very similar to AssertJ, since it was
inspired by FEST, of which AssertJ is a fork of the 2.0 development
line.
To sum up, Truth is designed to be a bit more extensible and flexible, but AssertJ will be great (possibly the greatest) for assertions on standard types.
Which one is better, in terms of performance , to use : by.css or by.xpath or by.id.
I have a really lengthy xpath :
by.xpath('//*#id="logindiv"]/div[3]/div/div[1]/div/nav/div/div[1]/form/div/div/button')
which can be used with other selectors like by.css or by.id.
But it is not very clear which one is better.
Protractor uses selenium-webdriver underneath for element lookup/interaction etc, so this is not protractor specific question, but rather selenium-webdriver specific.
CSS selectors perform far better than Xpath and it is well documented in Selenium community. Here are some reasons,
Xpath engines are different in each browser, hence make them inconsistent.
Last time I checked, IE does not have a native xpath engine, therefore selenium-webdriver injects its own xpath engine for compatibility of its API. Hence we lose the advantage of using native browser features that selenium-webdriver inherently promotes.
Xpath tend to become complex like your example and hence make hard to read/maintain in my opinion.
However there are some situations where, you need to use xpath, for example, searching for a parent element or searching element by its text (I wouldn't recommend the later).
You can read blog from Simon(creator of selenium-webdriver) here . He also recommends CSS over Xpath.
So I would recommend you use id, name etc for faster lookup. If thats not available use css and finally use xpath if none other suite your situation.
I am in the process of writing a toy compiler in scala. The target language itself looks like scala but is an open field for experiment.
After several large refactorings I can't find a good way to model my abstract syntax tree. I would like to use the facilities of scala's pattern matching, the problem is that the tree carries moving information (like types, symbols) along the compilation process.
I can see a couple of solutions, none of which I like :
case classes with mutable fields (I believe the scala compiler does this) : the problem is that those fields are not present a each stage of the compilation and thus have to be nulled (or Option'd) and it becomes really heavy to debug/write code. Moreover, if for exemple, I find a node with null type after the typing phase I have a really hard time finding the cause of the bug.
huge trait/case class hierarchy : something like Node, NodeWithSymbol, NodeWithType, ... Seems like a pain to write AND work with
something completly hand crafted with extractors
I'm also not sure if it is good practice to go with a fully immutable AST, especially in scala where there is no implicit sharing (because the compiler is not aware of immutability) and it could hurt performances to copy the tree all the time.
Can you think of an elegant pattern to model my tree using scala's powerful type system ?
TL;DR I prefer to keep the AST immutable and carry things like type information in a separate structure, e.g. a Map, that can be referred by IDs stored in the AST. But there is no perfect answer.
You're by no means the first to struggle with this question. Let me list some options:
1) Mutable structures that get updated at each phase. All the up and downsides you mention.
2) Traits/cake pattern. Feasible, but expensive (there's no sharing) and kinda ugly.
3) A new tree type at each phase. In some ways this is the theoretically cleanest. Each phase can deal only with a structure produced for it by the previous phase. Plus the same approach carries all the way from front end to back end. For instance, you may "desugar" at some point and having a new tree type means that downstream phase(s) don't have to even consider the possibility of node types that are eliminated by desugaring. Also, low level optimizations usually need IRs that are significantly lower level than the original AST. But this is also a lot of code since almost everything has to be recreated at each step. This approach can also be slow since there can be almost no data sharing between phases.
4) Label every node in the AST with an ID and use that ID to reference information in other data structures (maps and vectors and such) that hold information computed for each phase. In many ways this is my favorite. It retains immutability, maximizes sharing and minimizes the "excess" code you have to write. But you still have to deal with the potential for "missing" information that can be tricky to debug. It's also not as fast as the mutable option, though faster than any option that requires producing a new tree at each phase.
I recently started writing a toy verifier for a small language, and I am using the Kiama library for the parser, resolver and type checker phases.
Kiama is a Scala library for language processing. It enables convenient analysis and transformation of structured data. The programming styles supported by the library are based on well-known formal language processing paradigms, including attribute grammars, tree rewriting, abstract state machines, and pretty printing.
I'll try to summarise my (fairly limited) experience:
[+] Kiama comes with several examples, and the main contributor usually responds quickly to questions asked on the mailing list
[+] The attribute grammar paradigm allows for a nice separation into "immutable components" of the nodes, e.g., names and subnodes, and "mutable components", e.g., type information
[+] The library comes with a versatile rewriting system which - so far - covered all my use cases
[+] The library, e.g., the pretty printer, make nice examples of DSLs and of various functional patterns/approaches/ideas
[-] The learning curve it definitely steep, even with examples and the mailing list at hand
[-] Implementing the resolving phase in a "purely function" style (cf. my question) seems tricky, but a hybrid approach (which I haven't tried yet) seems to be possible
[-] The attribute grammar paradigm and the resulting separation of concerns doesn't make it obvious how to document the properties nodes have in the end (cf. my question)
[-] Rumour has it, that the attribute grammar paradigm does not yield the fastest implementations
Summarising my summary, I enjoy using Kiama a lot and I strongly recommend that you give it a try, or at least have a look at the examples.
(PS. I am not affiliated with Kiama)