Groovy именованные параметры вызывают переключение назначения параметров - как обойти это?

Groovy соберет все названные параметры в карту и передаст ее в метод в качестве первого параметра. Это кажется изящным, но после попытки заставить его работать кажется действительно непригодным для использования.

Итак, проблема заключается в следующем методе:

def method(paramMap, specificVar1 = 7, specificVar2 = 14)

когда вы вызываете этот метод примерно так:

method(12, extraValue: "hello")

вы получаете примерно то, что ожидаете:

assert 12 == specificVar1
assert 14 == specificVar2
assert [extraValue:"hello"] == paramMap

неплохо, имеет смысл. Проблема в том, что если вы предполагаете, что параметры Map необязательны, вы можете получить такие значения:

method(12)

assert paramMap == 12
assert specificVar1 == 7 // default values
assert specificVar2 == 14

Этот скаляр должен был попасть в конкретную переменную, а не в карту. Если я специально наберу карту в методе:

def method(Map paramMap, specificVar1 = 7, specificVar2 = 14)

тогда method(12, extraValue: "hello") работает так же, как и раньше, но method(12) выдает ClassCastException. Это просто бесполезно. Есть ли способ сделать этот Map "липким", чтобы он был просто пустым, если нет Map параметров?


groovy named-parameters
person Bill K    schedule 13.03.2013    source источник
comment
Билл К. обновил мой ответ очень простым решением. Надеюсь, поможет.   -  person Will    schedule 14.03.2013

Ответы (1)


arrow_upward
14
arrow_downward

Установка значений по умолчанию для параметров создает перегруженные методы с комбинациями, составленными слева направо, таким образом, трудно сделать method(12) и также иметь возможность передавать записи карты.

Ваш метод def method(paramMap, specificVar1=7, specificVar2=14) сгенерирует следующие методы:

Object Maps.method(java.lang.Object)
Object Maps.method(java.lang.Object,java.lang.Object)
Object Maps.method(java.lang.Object,java.lang.Object,java.lang.Object)

И полностью типизированный метод с параметром карты:

def method3(Map paramMap=[:], Integer specificVar1=7, Integer specificVar2=14) {
}

Сгенерирует следующие методы:

Object Maps.method3()
Object Maps.method3(java.util.Map)
Object Maps.method3(java.util.Map,java.lang.Integer)
Object Maps.method3(java.util.Map,java.lang.Integer,java.lang.Integer)

(Нет подходящего метода для method(12)).

Кроме того, записи, переданные в метод, будут собраны и вставлены в первый параметр map. Следующий метод:

def method4(Integer specificVar1=7, Integer specificVar2=14, Map map=[:]) {

Создает:

Object Maps.method4()
Object Maps.method4(java.lang.Integer)
Object Maps.method4(java.lang.Integer,java.lang.Integer)
Object Maps.method4(java.lang.Integer,java.lang.Integer,java.util.Map)

Таким образом, method4 12, a:'b' не работает с:

No signature of method: Maps.method4() is applicable for argument types: 
  (java.util.LinkedHashMap, java.lang.Integer) values: [[a:b], 12]

Так что нет, я не думаю, что вы можете делать то, что хотите, используя карты :-).

Решение 1.

Если вам нужно чисто динамическое решение, вы можете использовать единственный аргумент карты:

def method5(Map map) {
  def specificVar1 = map.specificVar1 ?: 7
  def specificVar2 = map.specificVar2 ?: 14
}

Решение 2 (обновлено):

Вы можете создать класс для представления параметров. Использование карты, которая должна быть приведена к объекту, статически компилируется и является для него синтаксическим сахаром.

@groovy.transform.CompileStatic
class Maps {
  def method6(Foo foo) { "$foo.params, $foo.specificVar1, $foo.specificVar2" }
  def method6(Map map) { method6 map as Foo }

  static main(args) {
    def maps = new Maps()

    assert maps.method6(params: [a: 'b', c: 'd'], specificVar1: 40) ==
        "[a:b, c:d], 40, 14"

    assert maps.method6(new Foo(params: [a: 'b', c: 'd'], specificVar2: 21)) == 
        "[a:b, c:d], 7, 21"
  }
}

class Foo {
  def specificVar1 = 7, specificVar2 = 14, params = [:]
}

Решение 3:

Перегруженный метод.

def method6(Map paramMap, Integer specificVar1=7, Integer specificVar2=14) {
  "$paramMap, $specificVar1, $specificVar2"
}

def method6(Integer specificVar1=7, Integer specificVar2=14) {
  method6 [:], specificVar1, specificVar2
}


assert method6( 12 ) == "[:], 12, 14"
assert method6( ) == "[:], 7, 14"
assert method6( a:'b', 18 ) == "[a:b], 18, 14"
assert method6( 18, a:'b', 27 ) == "[a:b], 18, 27"
assert method6( 90, 100 ) == "[:], 90, 100"
assert method6( a:'b', 140, c:'d' ) == "[a:b, c:d], 140, 14"

Метод версии карты не может иметь параметр по умолчанию, иначе оба метода будут генерировать method6 без параметров, и они будут конфликтовать.

person Will    schedule 13.03.2013
comment
Хороший анализ. Я склоняюсь к решению с одной картой, но это делает его использование немного сложнее (безопасность типов, простой список параметров с первого взгляда ...), но это может быть лучшее, что мы можем сделать в текущем Groovy. - person Bill K; 14.03.2013
comment
Это потрясающе. Я люблю Решение 3! Большое спасибо за ваше время и настойчивость @Will. Бьюсь об заклад, есть способ сгенерировать подпись пересылки из аннотации и methodMissing (эти классы уже расширяют базовый класс, поэтому я уверен, что смогу заставить его работать именно так, как я хочу, с вашим трюком). Хотелось бы, чтобы был способ вознаградить за это дополнительную репутацию - Может быть, я смогу с наградой, мне нужно разобраться в этом! - person Bill K; 14.03.2013
comment
Кстати, я пытаюсь создать класс, в котором каждый метод запускается из командной строки, а также легко вызывается из кода (один класс со множеством небольших скриптов в нем). В настоящее время я использую (List, Map) и анализирую аргументы CLI в форме a = b на карте и помещаю остальные аргументы по порядку в список, но с этой подписью не очевидно, как вызвать его из код, мне всегда нужно думать о параметрах / порядке списка. - person Bill K; 14.03.2013
comment
Не уверен, что понял ... у вас есть класс, который анализирует groovy CliParser.groovy "coolClazz.method1(a, b, c, 90.0)"? - person Will; 14.03.2013
comment
В настоящее время я не использую CliParser, но могу использовать его для следующей итерации, над которой я работаю - теперь я разбираю его вручную. Каждый сценарий расширяет родительский класс - родительский класс сокращает командную строку, просматривает первый аргумент, находит метод в дочернем классе с таким же именем и вызывает его с остальными параметрами. Аннотации к каждому классу позволяют мне распечатать список доступных скриптов (методов с текстом документации из аннотации) в любом классе. Теперь он работает хорошо, за исключением неудобных параметров. - person Bill K; 14.03.2013
comment
Я только что придумал CliParser, не знаю, существует ли он :-). Что, если вы выберете решение для карт? Вам нужно будет ввести имя параметров, но порядок не имеет значения ... - person Will; 14.03.2013
comment
В Groovy есть CliBuilder - он предназначен для использования с обычными скриптами, разбивает на карту такие вещи, как -x = 7, и может распечатать использование. Решение карты могло бы работать, но я бы предпочел, чтобы программный вызов был как можно более естественным. В настоящее время решение List, Map вызывает боль, потому что оно не помогает вам понять, что вам нужно передать в метод, вместо этого вам нужно просмотреть код, чтобы понять это. Думаю, моя главная цель - потребовать как можно меньше от каждого скрипта / метода. - person Bill K; 14.03.2013