Общепринятая практика набора Scala

Вы возвращаете ссылку на массив, а не сумму. Также на каждой итерации вы создаете новый массив, из-за которого предыдущие значения теряются.

Просто переместите инициализацию за пределы цикла:

public static int[] allRowSums() {
    int rowSum = 0;
    int current = 0;
    int[] a = new int[values.length];        // observe this change (only 1 change made)
    for (int i = 0; i < values.length; i++) {
        for (int j = 0; j < values[current].length; j++) {
            rowSum = values[current][j];
            a[i] += rowSum;
        }
        rowSum = 0;
        current++;
    }
    return a;
}

И, как упоминалось в комментариях, вы печатаете ссылку на массив, используйте Arrays.toString(), чтобы распечатать массив.

System.out.println(Arrays.toString(allRowSums()));
31
задан Eugene Yokota 15 December 2010 в 20:18
поделиться

4 ответа

Почему List и Seq определяются в пакете scala и не scala.collection (даже при том, что реализации Seq находятся в подпакетах набора)?

Поскольку их считают столь обычно полезными, что они автоматически импортируются во все программы через синонимы в scala. Predef.

Каков стандартный механизм для инициализации набора и затем замораживания его (который в Java достигается путем обертывания в немодифицируемом)?

Java не имеет механизма для замораживания набора. Это только имеет идиому для обертывания (все еще модифицируемый) набор в обертке, которая выдает исключение. Надлежащая идиома в Scala должна скопировать изменяемый набор в неизменный - вероятно, использование: _ *

Почему некоторые типы набора (например, MultiMap) только определены как изменяемые? (Нет никакого неизменного MultiMap)?

Команда/сообщество просто еще не добралась там. 2,7 ответвления видели, что набор дополнений и 2.8, как ожидают, будет иметь набор больше.

Следующее кажется немного громоздким из-за вынужденных полных объявлений пакета:

Scala позволяет псевдонимы импорта, таким образом, это является всегда менее подробным, чем Java в этом отношении (см., например, java.util. Дата и java.sql. Дата - использующий обе силы один, чтобы быть полностью определенным)

import scala.collection.{Set => ISet}
import scala.collection.mutable.{Set => MSet}

class MyScala {
  var mySet: ISet[String] = null 

  def init(): Unit = {
     val s = MSet.empty[String]
     s + "Hello"
     s + "World"
     mySet = Set(s : _ *)
  }
}

Конечно, Вы действительно просто записали бы init как def init() { mySet = Set("Hello", "World")} и сохраните всю проблему или еще лучше просто поместите ее в конструктора var mySet : ISet[String] = Set("Hello", "World")

26
ответ дан 27 November 2019 в 22:36
поделиться

A couple of random thoughts:

  1. I never use null, I use Option, which would then toss a decent error. This practice has gotten rid of a ton NullPointerException opportunities, and forces people to write decent errors.
  2. Try to avoid looking into the "mutable" stuff unless you really need it.

So, my basic take on your scala example, where you have to initialize the set later, is

class MyScala {
  private var lateBoundSet:Option[ Set[ String ] ] = None
  def mySet = lateBoundSet.getOrElse( error("You didn't call init!") )

  def init {
     lateBoundSet = Some( Set( "Hello", "World" ) )
  }
}

I've been on a tear recently around the office. "null is evil!"

4
ответ дан 27 November 2019 в 22:36
поделиться

Обратите внимание, что могут быть некоторые несоответствия в API коллекций Scala в текущей версии; для Scala 2.8 (который будет выпущен позже в 2009 г.) API коллекций подвергается капитальному ремонту, чтобы сделать его более согласованным и гибким.

См. эту статью на веб-сайте Scala: http: //www.scala-lang .org / node / 2060

Чтобы добавить к примеру Тристана Юричека с lateBoundSet: Scala имеет встроенный механизм для отложенной инициализации с использованием ключевого слова "lazy":

class MyClass {
    lazy val mySet = Set("Hello", "World")
}

При этом mySet будет инициализирован первым используйте, а не сразу при создании нового экземпляра MyClass.

3
ответ дан 27 November 2019 в 22:36
поделиться

Изменяемые коллекции иногда полезны (хотя я согласен, что вы всегда должны смотреть сначала на неизменных). Если я использую их, я обычно пишу

import scala.collection.mutable

в верхней части файла и (например):

val cache = new mutable.HashMap[String, Int]

в моем коде. Это означает, что вам нужно написать только «mutable.HashMap», а не scala.collection.mutable.HashMap ». Как упоминал выше комментатор, чрезмерное бремя.

(Кроме того, могу ли я повторить комментарий «избегайте нулей». Это делает код намного более надежным и понятным. Я считаю, что мне даже не нужно использовать Option столько, сколько вы ожидаете. .)

7
ответ дан 27 November 2019 в 22:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: