Add some helpful method to Predef?

Language Design
1

Hi, I am using Java at work and using Kotlin for tests, and there are some very helpful methods out of box in Kotlin:
eg:

repeat(times:Int, action: Int => Unit): Unit

and TODO(reason:String) which can accept messages

And the Result which lives in Rust too, I think those are very helpful for daily CRUD work, is it possible to have these in Scala’s Predef too?

2

I think they are discussing when they can do that and what to add or change.

Meanwhile, there is -Yimports:java.lang,scala,scala.Predef,com.acme.Predef

3 Likes
3

I really want Scala to be more popular and easier among daily CURD boys/girls :slight_smile:

4

I am not aware of a repeat or TODO method in the standard library, here is what I believe is usual:

for i <- 0 until times do action(i)
// or
(0 until times).foreach(action)
// Which usually will look like
for i <- 0 until times do
  val square = i * i
  assert(square >= 0)

(0 until 100).foreach{ i =>
  val square = i * i
  assert(square >= 0)
}

// TODO: reason
// something like the following might have editor support
// @TODO: reasong

As for Result, we have Either[Fail, Success], which works very similarly to an Option[Success], with the ability to store an error value of type Fail
(It also works as a disjoint union, as you can modify the Fail value with .left.map for example)

1 Like
5

Some history on Result is this topic. I think there has been a lot of interest since then.

On ch-ch-ch-ch-ch-ch-changing.

Sample times with sample usage at

scala> :javap scala.tools.nsc.symtab.classfile.ClassfileParser#parseAnnotation
[snip]
        37: iload         9
        39: iconst_0
        40: if_icmple     150
        43: aload_0
        44: invokespecial #470                // Method readName:()Lscala/reflect/internal/Names$Name;
        47: astore        11
        49: aload_0
        50: invokevirtual #1409               // Method parseAnnotArg:()Lscala/Option;
[snip]
       144: iinc          9, -1
       147: goto          37
6 
extension (times: Int) def timesDo(f: Int => Unit) =
   for i <- 1 to times do f(i)

inline def TODO(info: String) = throw NotImplementedError(info)


5.timesDo: i =>
   println(s"Doing iteration number: $i")

val notImplemnted = TODO("Because I'm lazy!")

I don’t think this belongs into Predef, though.

Still I would argue that Scala’s std. lib. is indeed missing a lot of convenience methods on all kinds of data structures. (Likely this is once more bad inheritance from Java.)

At the same time Scala’s std. lib. has way to much stuff in it which doesn’t belong into a std. lib., imho.

A std. lib. should provide imho only three things: Data structures (but not data-formats; like e.g. XML or JSON), and all kinds of algorithm on them. That’s the most important stuff. And second, interfaces to the underlying runtime system.

The above extension amounts to an example of an algorithm (even a very simple and basic one). So it would constitute imho a valid candidate for the std. lib.

As a general pointer to what I would consider a good approach for a std. lib.: C++'s and Rust’s std. libs are something worth copying, imho! Things like Python are very bad OTOH as it’s the kitchen sink, and therefore unmaintainable. (At this point even the Python people realized that, and are in the process of actively shrinking their std. lib by throwing away all the unmaintained crap).

1 Like
7

IMHO ??? // reason is already sufficient for this use case.

3 Likes
8

Not really.

  1. reason is now a part of the exception which can be logged or passed to client with rpc response or errorcode.
  2. If you don’t have the source code, the class decompiler will show the message too.
9

I agree with @Jasper-M that TODO(reason:String) makes not much sense. (Even it’s trivially implementable in Scala 3.)

Any possibly given reason why something is not implemented is completely irrelevant to end-users.

That’s something for code review comments.

Actually having any ??? / TODOs in release artifacts is imho a mayor bug. Something like that should never pass CI in release mode. You can’t just crash an app because someone calls a half implemented feature! If you you’re planing to release “half-features” like that a proper framework for feature flags should be used, which will proved proper info in end-user friendly ways if someone interacts with a half-way implemented feature. Uncaught exceptions should be only used to signal defects. (And placing somewhere some catch-all for NotImplementedErrors would be imho even a greater mess than throwing this errors in releases in the first place…)

Just my 2ct.

3 Likes