Tim Harper | 4 Feb 22:45 2016
Picon
Gravatar

Future.andThen should be deprecated

I think the behavior is tremendously surprising. That it returns a Future at all leads one to believe that "oh it's probably a future after the andThen completes".

I think `Future.onComplete` is wholly sufficient to modify side effecting code. Also, `Future.andThen` leads to further confusion because implies concatenation because of the `Function1.andThen` function.

I'd recommend that `Future.andThen` be deprecated. If people need to write side-effecting code, it's much clearer for them to use onComplete, which returns Unit and leaves little question as to it's affect on the value of the original future.

Tim

--
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.
Gareth Siret | 3 Feb 09:30 2016
Picon

Proposal to add collectors to Java Conversions so that a Java 8 stream can be collected to a Scala List.

Something like:


  def toList[T]() : Collector[T, ListBuffer[T], List[T]] = {

    val supplier = new Supplier[ListBuffer[T]] {
      override def get() : ListBuffer[T] = {
        new ListBuffer[T]
      }
    }

    val biConsumer = new BiConsumer[ListBuffer[T], T] {
      override def accept(buffer: ListBuffer[T], t : T): Unit = {
        buffer.append(t)
      }
    }

    val combiner = new BinaryOperator[ListBuffer[T]] {
      override def apply(t: ListBuffer[T], u: ListBuffer[T]) : ListBuffer[T] = {
        t.appendAll(u)
        t
      }
    }

    val finisher = new java.util.function.Function[ListBuffer[T], List[T]] {
      override def apply(t : ListBuffer[T]) : List[T] = {
        t.toList
      }
    }
    Collector.of(supplier, biConsumer, combiner, finisher)
  }

Does anyone have any thoughts on whether this is a good plan?

--
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.
Petr Novak | 29 Jan 11:11 2016
Picon

Why trait "extends" class instead of "with" when class extends only a trait(s)?

Hi,
I'm used to understand inheritance like "what it is" (or behave as) and mixins as "what is has". Anytime I see things like "class Person extends Logging" it confuses me. Why we can't write "class Person with Logging"? Is there any reason for it, like Java interop, or it has been overseen?

The only solution I'm aware of to adhere to formalism would be to write "class Person extends AnyRef with Logging":( (I haven't actually try it though)

Many thanks.
Petr

--
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.
Koert Kuipers | 26 Jan 17:47 2016

functions pretty print

scala> val f1 = { (x: String) => x + "!" }
f1: String => String = <function1>

scala> println(f1)
<function1>


wouldn't it be nice if functions (Function1, Function2, etc.) print out the actual code? is this something that can be done with macros maybe?
the current toString is not very helpful or informative.

--
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.
Simon Ochsenreither | 21 Jan 15:46 2016
Picon

FAQ: Why does Scala use "i: Int" syntax instead of "Int i"?

Proposed text:
========================================

While both syntactic approaches seem to be roughly equivalent on a cursory look, the advantages become clear when investigating how the syntax scales to larger examples.

Instead of i: Int and Int i, let's have a look at a generic method definition and its usage

class Bar[T](t: T) {
  def foo[S, T](s: S): T = ???; foo[Int, String](42)
}


to discover some desirable properties:
  1. consistency in declarations like classes, methods, ...:
    Regardless of whether we define a class or a method, the ordering is the same: keyword – name – type parameters – value parameters – body
  2. consistency between declaration and usage:
    the invocation of foo mirrors the declaration of foo – you just supply an argument to every parameter
  3. declaration before use: the type variable name is introduced before it is used.
  4. clear nesting/scoping: It should be obvious to the reader to which type variable a type parameters refers to.
If we check alternative syntactic approaches against these properties, we will see that all of them fail at least one of these properties:

class Bar[T](T t) { – or – class [T] Bar(T t) {
  [S, T] T foo(S s) = ???  // fails (1) and (2)
}

class Bar[T](T t) {
  T foo[S, T](S s) = ???  // fails (3) and (4): T is used before it is defined ... or does foo's return type refer to the T of the class?
}

Scala's approach provides consistency, reduces the mental complexity and let's users treat type parameters like the value parameters they already know: A method can have zero or more value parameter lists and zero or one type parameter lists.

========================================
Opinions? (I know that the wording around type variable, type parameter is not quite right ... need to fix that.)

--
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.
Janek Bogucki | 16 Jan 23:34 2016
Picon
Gravatar

Scaladoc: Deprecate <at> template leaving <at> documentable or adding <at> expanddoc

Hi,

Since <at> documentable has the same effect as <at> template but is a lot clearer in terms of what a user might expect it to do, deprecation of <at> template seems advisable.

Even better, deprecate both in favour of  <at> expanddoc.


Background

<at> documentable was added as a synonym of <at> template in this commit,

 - https://github.com/scala/scala/commit/6539a9ddc5ecdec65ef1d874999a200cee46b2c4
 
This commit explains the purpose of <at> template,

 - https://github.com/scala/scala-partest/commit/351d46692d2c32492355d9c9add3ad72a16ee8e3

The connecting issue is,

 - Issue: https://issues.scala-lang.org/browse/SI-5784

Here a bit more explanation about <at> template,

  val docExpandAllTypes = BooleanSetting (
    "-expand-all-types",
    "Expand all type aliases and abstract types into full template pages. (locally this can be done with the <at> template annotation)"
  )

Observations

While <at> template aligns with the language used in the Scala source code it has less useful connotations outside of that.

<at> documentable at least sounds as if it would be related to document generation.

Having reviewed the Scaladoc tag names I'd go a bit further and pick <at> expanddoc as a new synonym for two reasons,

  1. This aligns with the other documentation directive <at> inheritdoc
  2.  This echoes "-expand-all-types"
  3.  It strongly implies there will be more documentation when used

WDYT?

Janek

--
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.
Julien Lavergne | 14 Jan 19:03 2016
Picon
Gravatar

how to extend scala classes from groovy traits?

Hi All,

I have some traits in groovy and need to extend some scala classes from them.

How to handle that?

Any idea?

Thx for your feedbacks.

Julien.

--
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.
Julien Lavergne | 14 Jan 19:02 2016
Picon
Gravatar

scala classes extend from groovy traits ?

Hi All,

I have some traits in groovy and need to extend some scala classes from them.

How to handle that?

Any idea?

Thx for your feedbacks.

Julien.

--
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 | 11 Jan 18:55 2016
Picon
Gravatar

Why is an accessor required when defining an assignment method?

In

object foo { def x_=(x: Int) { } } foo.x = 2

there is an error, but in

object foo { def x_=(x: Int) { } def x = 3 } foo.x = 2

there is not. Could this restriction be lifted?

--
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.
Arno den Hartog | 31 Dec 05:16 2015
Picon

SIP proposal: uncurried update method was a mistake and should be deprecated

The current scalac implementation of the update method sugar only works correctly in the most basic cases.

I am arguing for an exactly-once-curried update method, more currying leads to intractable ambiguities.
I direct your attention to this here gist: https://gist.github.com/acdenhartog/a47fad6ebe8d32ff0ff5

This is not exactly the grand-vision sort of SIP proposal, more like the overdue housekeeping kind.
Also I have not read the Scala puzzlers yet, so I do not know if any of these issue are in there.

Best regards,
Arno

--
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.
Roman Tkalenko | 13 Dec 03:07 2015
Picon

Case class conversion to/from Map[String, Any] as a standard feature.

There is a number of StackOverflow topics and related blog posts 
dedicated to the problem of representing case classes as Maps (and back).
This is a highly popular question amongst those trying to avoid boilerplate 
or code repetition while providing ORMs, serializers,  custom object-database mappers etc.
For those who haven't had the opportunity to tackle this, here's what I'm talking about:

case class Apple(color: Color, size: Int) {
  def toMap(): Map[String, Any] = Map("color" -> color, "size" -> size)
  def fromMap(map: Map[String, Any] = new Apple(map("color"), map("size"))
}

Now imagine having tens of those classes and having to write that to-from methods all over again.

Some people manage to do it with Java's one, others go deeper and use Scala's reflect.runtime.
Fancy folks do the macros magic. There are more examples, but without going into much detail - 
most of these approachesare flawed in one way or another, 
i.e. reflection approach is ad-hoc and might lead to some internal field leakage, 
macros are an experimental feature and not everyone is ready to support them
in their libraries etc.

I'd like to hear if it seems a reasonable idea to do a proposal on having these two methods
as a standard language feature. The main motivation is that case classes are a perfect representation
for the domain-specific entities and every time people face the need to provide a representation 
of these entities to an external storage engine, they end up writing a custom code that solves
a common problem. Since case classes are already positioned as extremely simple replacement for POJO's,
why not make them even simpler?

--
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