Re: [isabelle-dev] ADTs in Scala
object Graph
{
// public operations to create ADT instances
}
final class Graph[Key, A] private(rep: SortedMap[Key, (A,
(SortedSet[Key], SortedSet[Key]))])
{
// implementation with access to rep
}
The main thing is the private in this odd position, which is Odersky's
way to make the constructor private, but the keep the type itself
public. This detail seems to have been forgotten in Java -- in fact in a
recent talk some Java guru admitted that -- which was also my starting
point to google for private constructor to find the above solution.
In fact, the pattern you used is quite common amongst Java developers,
they just call it Factory Pattern.
Next inappropriate question for Scala: How to avoid the ubiquitious NPE
problem of the JVM?
This question is not inappropriate at all. There is no single strategy
to avoid NPEs, but usually, Scala programs make extensive use of
`Option` to wrap anything that comes from a Java library to make sure
that there are no `null`s involved. Scala's API has a nice `Option`
factory for that: write `Option(value)`, and get `None` for `null` and
`Some(x)` for `x != null`. Obviously, computations then have to be
rewritten in applicative or monadic style. For the latter, Scala has
sugar in form of for comprehensions.
On a related note, there is also Scala library support to avoid the
general exception problem on the JVM. (see
http://www.scala-lang.org/api/current/index.html#scala.util.control.Exception$)
-- Lars
___
isabelle-dev mailing list
isabelle-...@in.tum.de
https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
Re: [isabelle-dev] ADTs in Scala
On Sat, 14 Apr 2012, Lars Hupel wrote: The main thing is the private in this odd position, which is Odersky's way to make the constructor private, but the keep the type itself public. This detail seems to have been forgotten in Java -- in fact in a recent talk some Java guru admitted that -- which was also my starting point to google for private constructor to find the above solution. In fact, the pattern you used is quite common amongst Java developers, they just call it Factory Pattern. I've heard of this recent addition to the OO vocabulary to fix some early conceptual problems of the approach. That is object Graph part only. How would a Java person solve the private constructor problem? Makarius ___ isabelle-dev mailing list isabelle-...@in.tum.de https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
Re: [isabelle-dev] ADTs in Scala
I've heard of this recent addition to the OO vocabulary to fix some early conceptual problems of the approach. That is object Graph part only. How would a Java person solve the private constructor problem? Could you explain a bit more? -- Java has private constructors. The source file 'graph.scala' looks fine the way it is now (except that you don't have to pass the implicit parameters around explicitly). Note that Scala allows secondary constructors, which would allow rewriting `empty` as def this(implicit ord: Ordering[Key]) = this(SortedMap.empty) However, I don't see that very often in practice. The advantage of `Graph.empty` is that it clearly communicates what this factory does. ___ isabelle-dev mailing list isabelle-...@in.tum.de https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
Re: [isabelle-dev] Towards the next release
On Fri, 13 Apr 2012, Lukas Bulwahn wrote: Since (2) is nothing specifically exciting by JUNG either -- it seems to be based on plain Java Graphics2D stuff -- I had recommended to abandon JUNG altogether. Did anything happen here in the meantime? We have discussed internally in more detail how to continue, but have not made any progress in the implementation itself. I have also spoken to Stefan Berghofer again, and encoraged him to help porting his great graph layout tool to Scala. Conceptually, the old graph browser can still compete with newer things on the market, but with its use of AWT from Java 1.1 that is hard to explain to end-users. (It is also technically hard to integrate into contemporary Swing components.) Before Stefan starts yet another implementation, we should make sure that the different projects converge. The idea was the same as before, when we had our joint discussion on the browser projects: join the efforts of Stefan from 1996 and Markus Kaiser from 2011. Makarius ___ isabelle-dev mailing list isabelle-...@in.tum.de https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
