> Нужно ли было плодить?

да, это разные сущности.

или null как признак отсутствия объекта по ссылке что было еще в С как NULL указатель или монада maybe или кастумные нули для каждого класса (container.end например из stl) но вобщем все суть одного и того же а именно объект есть или его нету

из всех подходов типизированный null как С, C# или монадический лучшие потому что позволяют компилятору проанализировать код и ткнуть кодера в те места где он забыл проверку на нуль

> да, это разные сущности.

Да я в курсе. Просто может можно было обойтись одним null-ом?

> Просто может можно было обойтись одним null-ом?

если ты действительно понимаешь, что это разные null-ы, то о каком вообще «обойтись одним null-ом» может идти речь? о_О

> если ты действительно понимаешь, что это разные null-ы, то о каком вообще «обойтись одним null-ом» может идти речь? о_О

Вон в рубях при обращении к словарю по несуществующему ключу возвращается nil. Вполне годно. В js почему-то undefined.

Нафиг делать два разных nil-а?

А в ерланге нет ни нула, ни нила. Живут же люди

вообще все верно. 2 нуля в js это чтобы различать _foo() и _foo(null) хотя от _foo(undefined) оно не спасет и на практике все пишут if(a == null) a = {} поэтому 2 нуля зря - достаточно одного null. кстати window.undefined = 1 усугубляет недоверие к undefined да и писать его длинно

> Вон в рубях при обращении к словарю по несуществующему ключу возвращается nil. Вполне годно. В js почему-то undefined.

хз как в рубях, но в перле в хэшах тоже есть два «nil-а»: exists($a{$b}) — запись в %a с ключом $b вообще существует, и defined($a{$b}) — записи $a{$b} присвоено хоть какое-нибудь значение. разница огромная.

>Вон в рубях при обращении к словарю по несуществующему ключу возвращается nil. Вполне годно.

Ужоснах. Вот и гадай потом, либо там ключ не существовал, либо существовал с nil-ом в паре. В Smalltalk кидается эксепшон, ну ты, наверно, знаешь

там пустой список?

В Smalltalk кидается эксепшон, ну ты, наверно, знаешь

Не, я Smalltalk пока так и не осилил. Хотя идея нравится. Чуть позже.

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

if dict[:key]
  # blah-blah
end

заместо что-нибудь вроде

begin
  value = dict[:key]
  
  # blah-blah
rescue KeyError => e
  error
end

Да, похоже возвращать специальное значение вроде undefined это третий, удобный вариант.

> там пустой список?

В ирлонге вродеж символы есть, вот тебе и null/true/false

Ещё вариант: кидать экспешен, но снабдить язык удобными maybe-like методами:

dict.if_have :key [ value |
  # blah-blah
]

Например, если в словаре значение есть, возвращается кортеж {ok, Value}, если нет — то undefined или false. Но undefined и false — это обычные атомы. Другая функция может возвращать not_found, notfound или что-нибудь другое. Короче, специального значения нет, есть некоторое множество атомов, которые обычно используется.

Ужоснах. Вот и гадай потом, либо там ключ не существовал, либо существовал с nil-ом в паре. В Smalltalk кидается эксепшон, ну ты, наверно, знаешь

Не нужно гадать, у хешей рубиновых есть метод has_key?, зато такое поведение может ощутимо упростить код, всяко проще чем ексепшены отлавливать.

вобщем те же яйца вид сбоку. имхо нулевость как префикс типа самое лучшее. можно писать var foo = bar[com] || default или забыть написать default и анализатор кода тебя ткнет носом

В Racket в функцию hash-ref третьим параметром передается значение, которое будет возвращено в качестве результата, если для ключа в таблице не определено значение.

в CL возвращается два значения, примерно как undet выше написал

> Нужен ли nil если есть false?

В школу.

>заместо что-нибудь вроде

Можно не ловить исключения, на то есть всякие #at:ifAbsent: и #at:ifAbsentPut: - первый метод в случае неудачи выполнит код в блоке (2й аргумент), второй метод положит значение блока (2й аргумент)

>Не нужно гадать, у хешей рубиновых есть метод has_key?

Ага, который возвращает true или false. Т.е. сначала делаем поиск со сложностью (надеюсь) O(ln(n)) по хешу чтобы проверить, есть ли там ключ, и потом опять такой же O(ln(n)) - чтобы получить несчастное значение. Отлично, так держать :)

если кешировать последний результат поиска то это невелируется :)

С каких это пор у хеша сложность O(ln(n)) ?

Ага, который возвращает true или false. Т.е. сначала делаем поиск со сложностью (надеюсь) O(ln(n)) по хешу чтобы проверить, есть ли там ключ, и потом опять такой же O(ln(n)) - чтобы получить несчастное значение. Отлично, так держать :)

Решения, в которых используют хеши, наверное в 90%, не вызовут каких-либо нареканий, даже если сложность будет O(n^2) или того хуже, тк часто размеры хешей мизерны. Если же это всеже становится проблемой, то в руби есть fetch, который, о чудо, может кидаться ексепшеном, если ключа не оказалось, либо передать конструктору хеша блок, который будет вызывать нужный ексепшен. Так что нечего тут на руби гнать)

В Objective-C есть NULL это null-pointer из C и nil - это в принципе тоже null-pointer но на Objective-C объект. Они равны по значению, но семантика разная.

>Objective-C
Он там до сих пор живее всех живых.

> В Scheme есть #f, но нет nil

Это в CL есть #f, но нету nil (ну или наоборот - есть nil, но нету #f), а в scheme есть и #f и nil.

>в руби есть fetch, который, о чудо, может кидаться ексепшеном, если ключа не оказалось, либо передать конструктору хеша блок, который будет вызывать нужный ексепшен.

Ну хоть так. Я верил, что в руби не все так плохо :)

В CL есть t и nil.

А разве нет?

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

Не знаю, как уж сделаны хэши в рубях, но поиск/вставка в расширяющиеся и красно-черные деревья тоже имеют сложность где-то около того.

> В CL есть t и nil.

Ну да, t и nil. А #f - нету, вместо него тот же nil.

> В плюсах (бинарный) поиск по мапе, которая представляет собой упорядоченный по ключу массив пар, имеет логарифмическую сложность.

Хеш-таблица - это не мап, это реализация мапа. Ну, типа - можно реализовать мап в виде того же красно-черного дерева с логарифмической сложностью, а можно - в виде хеш-таблицы, с константной :)

Вон в рубях при обращении к словарю по несуществующему ключу возвращается nil. Вполне годно. В js почему-то undefined.

[offtop]это смотря как хеш создан[/offtop]

http://avdi.org/devblog/2011/05/30/null-objects-and-falsiness/ ← статья на тему (на примере руби).

хеш != красно-черное дерево. тебе похоже Кнута курить надо

>Ну, типа - можно реализовать мап в виде того же красно-черного дерева с логарифмической сложностью, а можно - в виде хеш-таблицы, с константной

В дереве данные всегда будут отсортированы. Хеш такого сервиса не предоставляет.

> Это в CL есть #f, но нету nil (ну или наоборот - есть nil, но нету #f), а в scheme есть и #f и nil.

Я не буду писать комменты про предметы, в которых не разбираюсь. Я не буду писать комменты про предметы, в которых не разбираюсь. Я не буду писать комменты про предметы, в которых не разбираюсь.

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

В Схеме нет nil (есть null, это пустой список). #t и #f это другое вообще. В CL nil это отдельный символ, который можно использоваться в качестве схемовского #f. Пнятненько?

nil должен быть типизирован

Это все что от него требуется.

_________

//wfrr

Потмоу что в js нет словарей, там объекты.

_________

//wfrr

> nil должен быть типизирован

и какой же тип у него должен быть?

Соответствующий типу для которого он nil, не догадался да?

_________

//wfrr

> Соответствующий типу для которого он nil, не догадался да?

т.е. nil-ов на самом деле много. Для каждого типа свой отдельный экземляр nil.

А в чём профит?

Object d = getString() //d будет равен null setInt((Integer)d) //при null исключения не будет, еслиб null был бы типизированный, то было бы

_________

//wfrr

Object d = getString()

//d будет равен null

setInt((Integer)d)

//при null исключения не будет, еслиб null был бы типизированный, то было бы

_________

//wfrr

> В дереве данные всегда будут отсортированы. Хеш такого сервиса не предоставляет.

Это к чему ты сказал?

> В Схеме нет nil (есть null, это пустой список). #t и #f это другое вообще. В CL nil это отдельный символ, который можно использоваться в качестве схемовского #f.

Ну да. В схеме есть пустой список (он же Nil, он же null) и #f, причем #f != `(), в CL есть пустой список (он же Nil), но нету #f, т.к. вместо него Nil.

>Это к чему ты сказал?

Третью звезду хочу.