Привет всем.
Решил навести порядок в именах, не могу подобрать хорошеее и правильное название для функции.

Имеем:

Item* item_add(keys...); // создает новый элемент в контейнере в соотвестивии с ключом (или ключами) keys
Item* item_get(keys...); // возвращает элемент по keys или NULL
Item* item_get_or_create(keys...); // возвращает существующий элемент если он есть или создает новый

чем бы заменить слишком длинное имя item_get_or_create?

Здравствуйте, Kluev, Вы писали:

K>чем бы заменить слишком длинное имя item_get_or_create?

ensure, force_get
кстати, порядок слов у вас неестественный для английского языка

Здравствуйте, Kluev, Вы писали:

K>чем бы заменить слишком длинное имя item_get_or_create?

Да ничем ты ее не заменишь, не потеряв понятности.
Хотя если это коллекция однотипных элементов, то я бы убрал "item_", оставив просто add, get, get_or_create

Последний, являющийся прямой комбинацией get+add, тоже можно безболезненно убрать, используя функцию-хелпер там, где она нужна. Но это уже зависит от приложения в целом, может у вас полезно иметь ее именно в классе.

Здравствуйте, fmiracle, Вы писали:

А нельзя в get ввести булевский аргументик "создавать если нет?" ?

Здравствуйте, Andrei F., Вы писали:

И с чем несогласны несогласные?

Здравствуйте, Anpek, Вы писали:

A>Здравствуйте, fmiracle, Вы писали:

A>А нельзя в get ввести булевский аргументик "создавать если нет?" ?

а ещё можно завести enum ForceCreate { create };
И иметь get со вторым параметром типа ForceCreate....

Здравствуйте, Anpek, Вы писали:

A>Здравствуйте, fmiracle, Вы писали:

A>А нельзя в get ввести булевский аргументик "создавать если нет?" ?

Дополнительная косвенность — зло
Будут потом пихать туда какой-нибудь левый флаг и придётся дополнительно разбираться, чтож это за флаг, зачем он нужен и т.п.
Мелочь, но понимаемость кода уменьшает имхо.
(Ну и вообще сцепление по управлению не очень рекомендуют использовать, если уж функция что-то делает дак пусть делает, а не делает что-то что зависит от фазы луны)

Здравствуйте, Andrei F., Вы писали:

K>>чем бы заменить слишком длинное имя item_get_or_create?

AF>ensure, force_get
AF>И с чем несогласны несогласные?

force_get совсем непонятно. "Принудительно получить" ни как не ассоциируется с тем, что элемент будет создан в случае отсутствия.

ensure_get, т.е. "гарантированно получить" это несколько лучше, из такого названия можно понять, что элемент будет получен в любом случае, но непонятно будет ли получаемый элемент добавлен в коллекцию в случае его отсутствия или нет.

get_or_create же очень точное название, из которого сразу понятно, что произойдет при вызове.

Здравствуйте, Undying, Вы писали:

U>ensure_get, т.е. "гарантированно получить" это несколько лучше, из такого названия можно понять, что элемент будет получен в любом случае, но непонятно будет ли получаемый элемент добавлен в коллекцию в случае его отсутствия или нет.

Не вижу смысла в таком странном поведении.

Здравствуйте, Andrei F., Вы писали:

U>>ensure_get, т.е. "гарантированно получить" это несколько лучше, из такого названия можно понять, что элемент будет получен в любом случае, но непонятно будет ли получаемый элемент добавлен в коллекцию в случае его отсутствия или нет.

AF>Не вижу смысла в таком странном поведении.

Например, для Dictionary стандартное поведение это бросить исключение при обращении по несуществующему ключу, но часто бывает, что от Dictionary требуется безопасное поведение, т.е. нужно, чтобы при обращении по несуществующему ключу возвращался null, для чего пишется метод get_or_default(T key). Естественно вызов этого метода ничего в Dictionary добавлять не должен. Соответственно при использовании ensure_get непонятно скрывается ли под ним get_or_create или get_or_default.

Здравствуйте, Undying, Вы писали:

U>ensure_get,

Оригинально было просто "ensure", что встречается довольно часто.

Здравствуйте, Undying, Вы писали:

AF>>Не вижу смысла в таком странном поведении.

U>Например, для Dictionary стандартное поведение это бросить исключение при обращении по несуществующему ключу,

Что это за стандарт? Зависит только от библиотеки.

U> но часто бывает, что от Dictionary требуется безопасное поведение, т.е. нужно, чтобы при обращении по несуществующему ключу возвращался null, для чего пишется метод get_or_default(T key).

Нет, по-нормальному делается TryGetItem, которая или получить результат или узнать, что результата нет. get_or_default не даёт информации о результате и, в большинстве случаев, для словаря, бесполезна.

U>…Соответственно при использовании ensure_get непонятно скрывается ли под ним get_or_create или get_or_default.

Обычно, методы с префиком "ensure" смотрят: выполняется ли какое-либо условие, и если не выполняется, делают так, что бы условие выполнялось. Если условием является наличие элемента в контейнере, то что будет делать метод ensure, ИМХО, очевидно.

Здравствуйте, _FRED_, Вы писали:

_FR>Оригинально было просто "ensure", что встречается довольно часто.

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

Здравствуйте, Kluev, Вы писали:

K>Привет всем.
K>Решил навести порядок в именах, не могу подобрать хорошеее и правильное название для функции.

K>Имеем:
K>

K>Item* item_add(keys...); // создает новый элемент в контейнере в соотвестивии с ключом (или ключами) keys
K>Item* item_get(keys...); // возвращает элемент по keys или NULL
K>Item* item_get_or_create(keys...); // возвращает существующий элемент если он есть или создает новый
K>

K>чем бы заменить слишком длинное имя item_get_or_create?

Имхо посмотрите на это с такой стороны. Сейчас этим item_get_or_create пользуются те кому наплевать что они только что изменили коллекцию. Сделаем шаг в будущее и добавим пул рабочих потоков и опа это крешбаг.
Имеет смысл убрать этот метод а для простоты отлова всех кто им пользуется лучше завести вспомогательную функцию и название ее сделать еще длиннее — чтобы сразу было видно что тут проблема с порядком инициализации.

Здравствуйте, _FRED_, Вы писали:

U>> но часто бывает, что от Dictionary требуется безопасное поведение, т.е. нужно, чтобы при обращении по несуществующему ключу возвращался null, для чего пишется метод get_or_default(T key).

_FR>Нет, по-нормальному делается TryGetItem, которая или получить результат или узнать, что результата нет. get_or_default не даёт информации о результате и, в большинстве случаев, для словаря, бесполезна.

На практике логике выполнения программы в 99% случаях безразлично равно ли значение по ключу null или ключа в словаре нет вообще. Соответственно использование функции DictionaryHlp.GetValueOrDefault (или dictionary.FindObject на extension) логике программы никак не мешает, зато и лаконичнее и безопаснее в использовании.

_FR>Обычно, методы с префиком "ensure" смотрят: выполняется ли какое-либо условие, и если не выполняется, делают так, что бы условие выполнялось. Если условием является наличие элемента в контейнере, то что будет делать метод ensure, ИМХО, очевидно.

И как понять, что ensure проверяет именно наличие элемента в коллекции, а не что-то другое? Ладно бы еще метод ensure_get назывался, там хоть какой-то намек есть в названии.

Здравствуйте, Andrei F., Вы писали:

K>>чем бы заменить слишком длинное имя item_get_or_create?
AF>ensure, force_get

Собственно принцип такой, если мы по каким-то причинам считаем необходимым написать метод со сторонним эффектом, то смысл стороннего эффекта должен присутствовать в названии метода. В данном случае сторонним эффектом является создание элемента, а не его гарантирование или принуждение, поэтому в названии метода должно присутствовать слово create (или его точный синоним), а не слова связанные со сторонним эффектом метода весьма иносказательно.

Здравствуйте, Undying, Вы писали:

U>>> но часто бывает, что от Dictionary требуется безопасное поведение, т.е. нужно, чтобы при обращении по несуществующему ключу возвращался null, для чего пишется метод get_or_default(T key).
_FR>>Нет, по-нормальному делается TryGetItem, которая или получить результат или узнать, что результата нет. get_or_default не даёт информации о результате и, в большинстве случаев, для словаря, бесполезна.
U>На практике логике выполнения программы в 99% случаях безразлично равно ли значение по ключу null или ключа в словаре нет вообще. Соответственно использование функции DictionaryHlp.GetValueOrDefault (или dictionary.FindObject на extension) логике программы никак не мешает, зато и лаконичнее и безопаснее в использовании.

Ну значит у меня "неправильные" программы — TryGetValue постоянно пользуюсь именно потому что нет (и не надо) в стандартной библиотеке Ensure.

_FR>>Обычно, методы с префиком "ensure" смотрят: выполняется ли какое-либо условие, и если не выполняется, делают так, что бы условие выполнялось. Если условием является наличие элемента в контейнере, то что будет делать метод ensure, ИМХО, очевидно.

U>И как понять, что ensure проверяет именно наличие элемента в коллекции, а не что-то другое? Ладно бы еще метод ensure_get назывался, там хоть какой-то намек есть в названии.

Я думаю, что метод

TItem EnsureItem<TKey, IItem>(this IDictionary<TKey, IItem> source, TKey key, Func<TKey, TItem> creator);

никого бы не смутил непониманием логики своей работы Точно так же, если коллекция сама знает как создать элемент, метод

TItem EnsureItem(TKey key);

в интерфейсе коллекции выглядел бы осознанно.

Здравствуйте, _FRED_, Вы писали:

U>>Например, для Dictionary стандартное поведение это бросить исключение при обращении по несуществующему ключу,

_FR>Что это за стандарт? Зависит только от библиотеки.

Широко-распространенные бибилиотеки де-факто и задают стандарт.
За примером далеко ходить не надо: Hashtable из .Net Framework-а.

Здравствуйте, Kluev, Вы писали:

K>чем бы заменить слишком длинное имя item_get_or_create?

Умные дядьки рекомендуют для облегчения жизни явно разделять функции запрашивающие состояние и меняющие его.
Так что бей на два метода и не ошибешься.

Здравствуйте, Lloyd, Вы писали:

U>>>Например, для Dictionary стандартное поведение это бросить исключение при обращении по несуществующему ключу,
_FR>>Что это за стандарт? Зависит только от библиотеки.
L>Широко-распространенные бибилиотеки де-факто и задают стандарт.
L>За примером далеко ходить не надо: Hashtable из .Net Framework-а.

Не очень удачный пример неудачно спроектированного контейнера. Чего с него пример брать? Взгляни на более продуманный IDictionary<,>.