Какова лучшая практика при проверке типа хэш-значений в расширении ruby ​​C?

Question

Я разрабатываю расширение C для ruby, одна из функций из библиотеки C, к которой я обращаюсь, получает структуру параметров, которая, кажется, естественным образом переводится в хэш параметров в ruby-world.

Структура инициализируется известными значениями по умолчанию, когда хэш на стороне ruby ​​не определяет значение для данной опции. На стороне C у меня есть несколько таких строк:

VALUE tmp;

tmp = rb_hash_aref(r_hash, rb_str_new2("opt1"));

if(TYPE(tmp) == T_STRING){
  strcpy (c_learn_param->opt1, StringValuePtr(tmp));
}else{
  strcpy (c_learn_param->opt1, "default value 1");
}

Теперь моя проблема в том, что опция имеет определенное значение, но тип ruby ​​не имеет смысла в C.

Должен ли я вызвать ошибку типа даже для необязательного значения? это кажется излишним, я должен вернуться к дефолту? проблема с возвратом к значению по умолчанию состоит в том, что пользователь, передающий {"opt1" => 123}, будет видеть то же поведение, как если бы он не определил opt1, что кажется плохой идеей. Должен ли я отступить и напечатать предупреждение ruby? (люди вообще их читают?).

Answer 1

Вы, вероятно, должны принять хотя бы Символ или Строку, поскольку они на практике используются почти взаимозаменяемо (следовательно, ActiveSupport :: HashWithIndifferentAccess ).

В зависимости от вашей конкретной ситуации, возможно, имеет смысл вызвать to_s на вашем tmp и разрешить преобразовывать в него все, что угодно, таким образом. Однако, если имеет смысл принимать только строку или символ, то повышение TypeError является вполне разумным решением.

Быть настолько гибким, насколько это возможно, со своими входами, но строго со своими выходами, как правило, хорошая идея и делает для дружественных библиотек.

Если люди не читают предупреждений, то это их собственная вина, когда что-то идет не так, и у вас есть право ухмыляться и сказать: «Я вам так сказал».