Предыдущий день | Следующий день
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Статья Домашний каталог рассказывает про общее понятие, а статья /home — про его частный случай: домашний каталог в Unix-подобных операционных системах. К тому же существование двух отдельных статей вызывает интервики-конфликт. Гамлиэль Фишкин 00:45, 16 апреля 2013 (UTC)

  • Не совсем так. /home — это не домашний каталог, а каталог, обычно (но не обязательно) содержащий домашние каталоги. Сами эти каталоги имеют пути вида /home/username, хотя, как правильно замечено, могут встречаться и другие варианты (на нашем предприятии, например, принято /home/users/username), в том числе и не связанные с /home вообще. Статья /home — это скорее про элемент стандарта FHS, а не только про домашние каталоги. Mevedech 04:23, 16 апреля 2013 (UTC)
      1. Скажите, вы давно последний раз встречали /home, который бы не содержал домашние каталоги пользователей?
      2. Про предприятие - не понял. У вас же там все равно хранятся домашние каталоги пользователей. Да и в том же FHS рекомендуется для систем с большим количеством пользователей группировать их домашние каталоги
      3. В любом случае этот элемент стандарта описывает место размещения домашних каталогов пользователей
        Amcour 12:49, 28 октября 2013 (UTC)
  • Прошу прощения, моя реплика — это всего лишь скромное возражение тезису коллеги Гамлиэля Фишкина о том, что /home — это частный случай домашнего каталога (термин в единственном числе). Таким образом, статьи предлагается объединить на основании некорректного тезиса, вот это мне и показалось неправильным. В целом-то я вижу, что статья /home в нынешнем виде явно избыточна, и не против объединения её и с Домашним каталогом, и с FHS, поскольку предмет разговора, образно говоря, является пересечением этих тем. Кстати, нужно заодно разобрать и другие статьи, на которые ссылается Шаблон:FHS. Mevedech 05:47, 29 октября 2013 (UTC)

Итог

Консенсус за объединение. Phoenix720 уже перенес часть информации из /home в Домашний каталог. Ставлю перенаправление. --Mihail Lavrov 19:18, 17 октября 2015 (UTC)

Один и тот же населенный пункт.Шиманський Василь 10:47, 16 апреля 2013 (UTC)

Итог

Вторая статья - ботозаливка, из нее буквально одно предложение перенесено в первую. --Дарёна 10:42, 21 апреля 2013 (UTC)

Один и тот же населенный пункт.--Шиманський Василь 10:54, 16 апреля 2013 (UTC)

Итог

Объединено в Конельская Поповка --Дарёна 10:32, 21 апреля 2013 (UTC)

Для полноценной статьи о линейки надо обобщить. Статьи об отдельных моделях линейки ненужны - устаревают. ESSch 15:16, 16 апреля 2013 (UTC)

Может быть Вам и не нужны, но это не значит, что они не нужны никому. Все устаревает. Но это не означает, что не должно быть соответствующих статей. На Вашей страничке написано о Вас: "Этот участник — инклюзионист. Он полагает, что чем больше будет статей в Википедии, тем лучше." Так вот - что-то не похоже на правду. 195.68.175.223 08:40, 25 апреля 2013 (UTC)

Чем больше, тем лучше. Так давайте писать о каждой мыльнице... Я за написание обо всех линейках мыльниц, например Canonа, как это сделано в английской Википедии, но не об отдельных мыльницах - через год никому не интересных. Конечноже есть огромное колличество исключений, когда имеются уникальные фотоаппараты или модели сильно разнятся, но это, как правило, не цифровые.
Вспомним, что Википедия не справочник характеристик фотоаппаратов, с описанием когда вышел и по какой цене. Нужен обзор, сравнения, описание технологий. Обзор, описание технологий, конкуренты по этим трём статьям один, так как фотоаппарат не изменился (это всего-лишь обновления).
"что-то не похоже на правду." - мне нужно привести список написанных статей об фотоаппаратах? Некоторые приводят, они большие, так много статей о них, но окрываешь статью и видишь: три строчки (когда и по какой цене вышел) и огромная карточка. Таким статьям два пути: к удаления из-за слишком большой коротизны и википедия не справочник. Наивно думать, что их ко-то будет развивать... — Эта реплика добавлена участником ESSch (ов) 22:36, 25 апреля 2013 (UTC).

Итог

В линейке SD вышло уже 5 фотоаппаратов, если все их описывать в одной статьей Sigma SD, во-первых, информация будет подана не самым удобным для читателя образом (часть информации — о серии в целом, часть — о конкретных моделях), во-вторых, будет достигнут объём, при котором статьи рекомендуется разделять. Соответственно, смысла в объединении статей нет. →x← Не объединять — Максим 02:40, 26 апреля 2013 (UTC)

Отличаи только в семантике и алгоритма трансляции. ESSch 15:48, 16 апреля 2013 (UTC)

  • Давайте взглянем на английский проект: en:Operator overloading и en:Function overloading есть, причём первая содержательно вполне самостоятельная. Разница по сути такая же, как между указателем и ссылкой (англ.) — одно является важным частным случаем другого, достаточно важным для самостоятельного рассмотрения. Важность доказывается примером языка Standard ML: в нём напрочь отсутствует ad hoc полиморфизм, зато можно свободно вводить свои операторы, но опять же не перегружаемые, а уникальные. То есть можно ввести оператор, например «a >:=--=:< b». В Haskell можно поступать так же, но кроме этого доступна-таки и перегрузка, а кроме этого есть и третья фича — любую функцию с двумя аргументами можно использовать в инфиксной записи. Это, конечно, можно всё рассмотреть и в одной статье, но она станет очень большой и страшной. Я за то, чтобы оставить статьи раздельными. upd: То есть в ML получается, что «перегрузка» и «оператор» — это ортогональные, независимые концепции. По сути это означает, что в идеале нужно просто переименовать статью «Перегрузка операторов». Но как именно — пока не скажу, в литературе по ML это называется «символьными идентификаторами» (которые, кстати, и не обязательно должны быть инфиксными). Arachnelis 18:57, 1 апреля 2014 (UTC)

Итог

Отличия и в семантике, и в синтаксисе, и в реализации трансляторов, и что особо характерно: есть немало языков с перегрузкой процедур и функций, в которых нет перегрузки операторов, апологеты классического структурного программирования поддерживают перегрузку процедур и функций, но считают нецелесообразной или даже опасной в реализации перегрузку операторов. Обе статьи не в лучшем состоянии, возможно, выбраны неоптимальные наименования статей, но это повод для других видов обсуждений, а здесь — не объединено, bezik° 18:41, 31 декабря 2016 (UTC)