Последствия не включая ПУСТОЙ УКАЗАТЕЛЬ на языке?

Это не является онлайн-инструментом; вместо этого это приложение для Windows, больше похожее на RegexBuddy, но для XPath.

XPathVisualizer .

снимок экрана http://i29.tinypic.com/1zwp5ix.jpg

Заимствование страницы из монады Haskell's Maybe , как вы поступите в случае возвращаемого значения, которое может существовать или не существовать? Например, если вы пытались выделить память, но ее не было. Или, может быть, вы создали массив для хранения 50 foo, но ни один из foo еще не создан - вам нужен какой-то способ проверить такие вещи.

Думаю, вы можете использовать исключения для покрытия все эти случаи, но означает ли это, что программисту придется заключить все из них в блок try-catch? В лучшем случае это будет раздражать. Или все должно возвращать собственное значение плюс логическое значение, указывающее, было ли значение допустимым, что, конечно, не лучше.

FWIW, я не знаю ни одной программы, в которой нет some своего рода понятие NULL - у вас есть null во всех языках C-стиля и Java; Python не имеет Нет , Scheme, Lisp, Smalltalk, Lua, Все Ruby имеют nil ; VB использует Nothing ; и Haskell имеет другой вид ничего .

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

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

На ум сразу приходят параметры, передаваемые по ссылке. Я в первую очередь кодировщик Objective-C, поэтому привык видеть что-то вроде этого:

NSError *error;
[anObject doSomething:anArgumentObject error:&error];
// Error-handling code follows...

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

[anObject doSomething:anArgumentObject error:nil];

Поскольку я не передаю никакого фактического значения для объекта ошибки, я не получаю никаких результатов, и я действительно не беспокоюсь о разборе ошибки (поскольку я в первую очередь не волнует, если это произойдет).

Вы уже упоминали, что обрабатываете ошибки другим способом, поэтому этот конкретный пример на самом деле не применим, но суть остается в силе: что вы делаете, когда передаете что-то обратно по ссылке? Или ваш язык просто этого не делает?

Я считаю полезным, чтобы метод возвращал NULL - например, для метода поиска, который должен возвращать некоторый объект, он может возвращать найденный объект или NULL, если он не был найден.

Я начинаю изучать Ruby, а в Ruby есть очень интересная концепция NULL, возможно, вы могли бы подумать о реализации чего-нибудь silimar. В Ruby NULL называется Nil, и это реальный объект, как и любой другой объект. Он реализован как глобальный объект Singleton. Также в Ruby есть объект False, и оба Nil и False оценивают значение false в логических выражениях, в то время как все остальное оценивается как true (даже 0, например, оценивается как true).

Я предпочитаю, чтобы по умолчанию использовались указатели, не допускающие значения NULL, с возможностью использования указателей, допускающих значение NULL. Вы можете почти сделать это с помощью C ++ с помощью ссылок (&), а не указателей, но в некоторых случаях это может стать довольно грубым и утомительным.

Язык может обойтись без null в смысле Java / C, например Haskell (и большинство другие функциональные языки) имеют тип «Может быть», который по сути является конструкцией, которая просто предоставляет концепцию необязательного нулевого указателя.

На мой взгляд, есть два случая использования, для которых обычно используется NULL:

• У рассматриваемой переменной нет значения (Nothing)
• Мы не знаем значение рассматриваемой переменной (Неизвестно)

Оба распространенных случая и, честно говоря, использование NULL для обоих может вызвать путаницу.

Стоит отметить, что некоторые языки, которые не поддерживают NULL, не поддерживают ничего из Nothing / Неизвестно. Haskell, например, поддерживает «Maybe», которое может содержать либо значение, либо Nothing. Таким образом, команды могут возвращать (и принимать) тип, который, как они знают, всегда будет иметь значение, или они могут возвращать / принимать «Может быть», чтобы указать, что может не быть значения.

Мне непонятно, почему вы хотите исключить из языка понятие «нуль». Что бы вы сделали, если бы ваше приложение потребовало от вас выполнить некоторую "ленивую" инициализацию - то есть вы не выполняете операцию, пока не потребуются данные? Пример:

public class ImLazy {
 public ImLazy() {
  //I can't initialize resources in my constructor, because I'm lazy.
  //Maybe I don't have a network connection available yet, or maybe I'm
  //just not motivated enough.
 }

 private ResourceObject lazyObject;
 public ResourceObject getLazyObject() { //initialize then return
  if (lazyObject == null) {
   lazyObject = new DatabaseNetworkResourceThatTakesForeverToLoad();
  }
 }

 public ResourceObject isObjectLoaded() { //just return the object
  return (lazyObject != null);
 }
}

В таком случае, как мы могли бы вернуть значение для getObject ()? Мы могли бы придумать одно из двух:

-требовать от пользователя инициализировать LazyObject в объявлении. Затем пользователю нужно будет заполнить какой-то фиктивный объект (UselessResourceObject), который требует от них написания одного и того же кода проверки ошибок (если (lazyObject.equals (UselessResourceObject) ...) или:

- придумать какое-то другое значение, которое работает так же, как null, но имеет другое имя

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

Здесь происходит интересное обсуждение.

Если бы я создавал язык, я действительно не знаю, было бы у меня понятие null . Думаю, это зависит от того, как я хочу, чтобы язык выглядел. Показательный пример: я написал простой язык шаблонов, главная сила которого - вложенные токены и простота превращения токена в список значений. В нем нет концепции null, но и в нем нет концепции каких-либо типов, кроме строки.

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

В PHP я иногда использую null в качестве «третьего» логического значения. Это хорошо для классов типа «черный ящик» (например, ядра ORM), где состояние может быть Истина, Ложь или Я не знаю. Для третьего значения используется Null.

Конечно, в обоих этих языках нет указателей, как в C, поэтому нулевые указатели не существуют.

Мы постоянно используем нули в нашем приложении, чтобы представить случай «ничего». Например, если вас просят найти некоторые данные в базе данных с заданным идентификатором, и ни одна запись не соответствует этому идентификатору: верните null. Это очень удобно, потому что мы можем хранить нули в нашем кеше, а это значит, что нам не нужно возвращаться к базе данных, если кто-то снова запросит этот идентификатор через несколько секунд.

Сам кеш имеет два разных типа ответов. : null, что означает отсутствие такой записи в кэше или объекта записи. Объект записи может иметь нулевое значение, что имеет место, когда мы кэшируем поиск в базе данных с нулевым значением.

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