Lukas Wegmann | 20 Apr 11:57 2015
Picon

Disable Conversion to Unit

Hi,

I recently spent hours to track a bug due to the automatic conversion to Unit.

Finally, the issue boiled down to a swallowed exception because a Try[Unit] has been converted to Unit:

def f(i: Int): Try[Unit] = Try{ throw new ArrayIndexOutOfBoundsException }

def g(): Unit = f(42) // will never throw, but f(42).get would

I'm now wondering if one could also get along without the automatic conversion to Unit? I think this behavior is a bit off from the general convention in Scala of making destructive operations explicit. E.g. converting a Float to an Int.

What do you think? Would a compiler flag that disables this conversion make sense or is there some invaluable benefit I've missed?


Lukas

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Eric Kolotyluk | 25 Mar 02:16 2015
Picon

Wacky Fantasies in Documentation

I was trying to get something working by reading the ScalaDoc. The 
documentation was actually quite good by Scala standards, complete with 
examples even. Unfortunately, there were some errors in the example code 
that took me a while to figure out. Then I started to have this fantasy...

I wonder if it would be possible to define example code in scaladoc 
comments such that when you generated your documentation at build time 
in scaladoc, it would run the example code like a unit test, and fail 
the build if the example code did not compile and execute.

One of my colleagues started buying into my fantasy and even suggested 
that the scaladoc comments link to actual unit tests. Often studying 
unit tests can be the best example of understanding a library or 
framework. Indeed, I have seen a number of projects in GitHub that refer 
you to the unit tests for examples of how to use the API or framework. 
Of course this would imply that you would actually want to write good 
scaladoc comments for your unit tests too. OMG - now I am speaking 
heresy. What if the unit test framework actually help generate 
meaningful documentation to explain what what going on?

My experience with documentation has been that it is often hard to test 
documentation, to test that it is actually correct. What if we could 
help improve documentation by using automated methods to test it, or at 
least a part of it, such as examples.

Cheers, Eric

--

-- 
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Justin Pihony | 18 Mar 20:16 2015
Picon

Opinion requested for ScalaDocs change

All,
    I first posted this on the internals group, and then the users group, and was suggested to post it here. If you have any input in a more searchable scaladoc, then please put your two cents in :)

    The current state of scaladocs does not allow for easy searchability between companion objects. This issue was created to help the problem by combining the companion pages. The thought is that it will help discovery by allowing an easier Ctrl+F. I am asking for a consensus of opinions on how this should be accomplished. If you go to this link, you will see the current state of the propositions. 

The constant across all changes is the structure of the member definition.
The part that is in question revolves around the top level documentation; whether it should be combined or not. If so, what is the best way of combining:


Please review and let me know what you think is the best solution.

Thanks,
Justin

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rich Oliver | 16 Mar 16:11 2015
Picon

Is Object-Orientated Programming misnamed?

Would it be more accurate to call Object-Orientated Programming Subject-Orientated programming?

The so called objects are in fact dynamic subjects. This is both their power and their danger. A so called object can do anything it wants when you call a method on it: print out helpful feedback, log information, launch a nuclear missile, or upload your personal data to a Server.. This is why Java strings are finalised, because if you could override methods on strings it would create huge security holes. On the JVM its ints, floats doubles etc that are the true objects, passive dumb objects that rely on external function calls to do anything with. The same with classic C data. Again just dumb objects. Surely its C that should be classifed as an object orientated language?

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
MichaelZ | 16 Mar 01:47 2015
Picon

why "Hi:%.1G".format(0.0) does not work? Puzzled.

why "Hi:%.1G".format(0.0) does not work? Puzzled.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Som Snytt | 14 Mar 23:28 2015
Picon

GSOC diversion


I can't believe it's almost summer!

If I can find a mentor, I would like to tackle the first project idea, dealing with project organization and aggregation in Scala:

http://scala-lang.org/gsoc/2015.html#project_titles_go_here_with_h3_headings

Since naming is the hardest problem in computer science, I realize that a single summer of coding is not sufficient to achieve a robust implementation.

Probably actually coming up with titles is out of scope.

But given a source of random words, such as a dictionary or an EPFL student, it should be possible to generate corresponding headings.

If I can formalize it in a paper, which Scala conference should I present at? I have a travel budget of about 3/4 of a tank of gas.

I propose that as proof-of-concept, the tool should emit JSON output, and the conversion to h3's can be tackled by the community using Scala.js.

BTW, at first I thought Scala.js was the user group for the isle of Jersey, but that would be Scala.je. To avoid such problems in future, I hope to add a lint filter to the project title tool.

One solution would be to mangle names, such as "scala$backend$javascript". The mangling would be completely invisible to the user. Does the community have any experience with that?

I can't wait to start coding in Scala, so I will likely go ahead without a mentor.

I am confident I can complete the project in 1/3 the lines it would have taken me in Java.

Summertime, and the coding is easy.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Radek Slupik | 10 Mar 22:32 2015
Picon

Making ScalaDoc show preconditions and postconditions.

Currently calls to require and ensuring merely turn into assertions. Would it be reasonable to make ScalaDoc put these in the documentation as well?

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Owen | 7 Mar 04:57 2015
Picon

How can casting to Nothing be improved?

Hello all,

It is common in Java to write unsafe generic methods like the following:
public class HasGenericMethod { public static <A> A genericMethod() { return (A) "Concrete Result"; } }I'm not saying people should write methods like the above, just observing that it appears commonly in heavily-used Java APIs (example: FXMLLoader.load()).

This can lead Scala to give an error at runtime:
object UsesGenericMethod extends App { val result = HasGenericMethod.genericMethod }
Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to scala.runtime.Nothing$
    at UsesGenericMethod$.delayedEndpoint$UsesGenericMethod$1(UsesGenericMethod.scala:3)

Because the parameter A has no constraints, scalac leaves it as Nothing. Then, a runtime cast to Nothing fails because String is not a subtype of Nothing. This can be surprising because, aside from the cast to Nothing, there isn't really anything wrong with the code. It is worth noting that although the Java method genericMethod() is clearly unsafe, it doesn't actually do any runtime casting and so it isn't responsible for the exception.

I feel something about this should be changed, but I am not sure what.

Best,
Owen

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rado Buransk√Ĺ | 24 Feb 21:50 2015
Picon

Extremely slow patmat phase of compilation

Can anybody tell me why this code takes endless time  to compile? What is the compiler doing so much and how can I help it?

You can find full source code here:
https://gist.github.com/RadoBuransky/d1d763a8f3c6555ee89a

sealed trait C
case object C1 extends C
case object C2 extends C
case object C3 extends C
...
case object C399 extends C
case object C400 extends C

object M {
  def f(c: C): Int = c match {
    case C1 => 1
    case C2 => 2
    case C3 => 3
    ...
    case C399 => 399
    case C400 => 400
  }
}

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Matthew Pocock | 18 Feb 14:03 2015
Picon

verbose enhancement syntax

I often end up with a typeclass and a syntax that converts each method of the typeclass to act as infix notation.

trait Foo[T] {
  def asString(t: T): String
  def asInt(t: T): Int
}

implicit class FooSyntax[T](val t: T) extends AnyVal {
  def asString(implicit foo: Foo[T]): String = foo.asString(t)
  def asInt(implicit foo: Foo[T]): Int = foo.asInt(t)
}

This is an extremely boring and mechanical re-write. Is there some way that we can manufacture the syntax mechanically from the typeclass?

Matthew

--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550
mob: +447535664143

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Eric Kolotyluk | 17 Feb 17:27 2015
Picon

Exhausting Akka Receive

In http://doc.akka.io/docs/akka/snapshot/scala/actors.html it gives the example
  1. import akka.actor.Actor
  2. import akka.actor.Props
  3. import akka.event.Logging
  4.  
  5. class MyActor extends Actor {
  6. val log = Logging(context.system, this)
  7. def receive = {
  8. case "test" => log.info("received test")
  9. an>case _ => log.info("received unknown message")
  10. }
  11. }
Wouldn't it be better practice to use
  1. import akka.actor.Actor
  2. import akka.actor.Props
  3. import akka.event.Logging
  4.  
  5. class MyActor extends Actor {
  6. val log = Logging(context.system, this)
  7. def receive = {
  8. case "test" => log.info("received test")
  9. case message: Any => log.error(s"received unknown message = $message")
  10. }
  11. }
First off, having better diagnostic information in the log is a good thing, is it not? Why does so much Scala documentation take the lazy way out and only ever give the bare essentials. Why does Scala documentation so rarely go a little further and demonstrate some better practices, especially when it is trivial to do?

Second, an unknown message is an error, it's not just information.  Often people, and monitoring systems, ignore "info" messages, and only pay attention to warnings, errors, and worse. There seems to be this general sense of laziness in the Scala, Akka, Play, etc. community to ignore problems, and train others to ignore them as well.

Coming from a Java background, the Scala community seems to just care less about quality, and more about typing less.

- Eric

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Gmane