Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  23:18[Войти] | [Зарегистрироваться]
Обсуждение темы:
Оберон-технология: особенности и перспективы


Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение. 

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 6256 сообщений

Добавить свое сообщение

Отслеживать это обсуждение

Обсуждение из раздела
Школа ОБЕРОНА

<<<... | 3726—3717 | 3716—3707 | 3706—3697 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 255


№ 3716   07-04-2007 12:23 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3714« (Trurl)
___________________________
А если это handle := open(name, mode) ?


А если это
h := o(n,m)

Утрировать конечно можно все. Вот только выбор названий для всех сущностей в программе является обязанностью программиста, и никакой импорт эту обязанность не отменял и не заменял.
В ООП можно позволить себе generic имена типа open, поскольку там это метод класса, который и идентифицирует операцию.
В ФП, называть функции такими именами в языках без обязательного квалификатора - ошибка программиста.
А вот в Эрланге - ради бога можно и file.open :))


№ 3715   07-04-2007 12:16 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3710« (Илья Ермаков)
___________________________

Не знаю, нужно ли рассказывать, кто такой бывший главный архитектор Microsoft Чарльз Саймони (Charles Simonyi) и что есть венгерская нотация (Hungarian notation). Word, Excel и Windows создавались под его руководством.

В начале 1960-х гг. Саймони на своей родине в Венгрии писал программы для советского компьютера "Урал-2". Именно тогда, работая в машинных кодах, он и приобрел умение создавать максимально эффективные программы, функционировавшие в условиях крайне ограниченных машинных ресурсов. Привычка делать мнемонические обозначения вылилась у него в создание того стиля формирования идентификаторов, который теперь известен под названием "венгерская нотация". См., например, http://en.wikipedia.org/wiki/Hungarian_Notation

Во многих языках во избежание недопонимания (какому типу или модулю принадлежит сущность) в само имя зашивают "тег принадлежности". Для квалифицирующего импорта "зашитие" выливается в квалификацию (обязательную). Более того, максимальный эффект от этого IMHO был достигнут в языке Modula-3 -- где в случае использования модуля как контейнера одного АТД (абстрактного типа данных) использовался обычно лаконичный унифицированный идентификатор (T). Например, Stack.T, Set.T и т.д.


№ 3714   07-04-2007 12:15 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3702« (Jack Of Shadows)
___________________________
Квалифицировать всегда только потому что в одном из ста случаев может случиться неявная подмена, это экстремизм, то есть доведение до крайнего случая. Любителей экстремизма всегда хватает, но большинство вас не поймут.
В одном из ста – это очень много. Реально бывает гораздо меньше. Тем не менее, разработчики и пользователи Эрланга – явные экстремисты. Может быть, именно поэтому их системы так надежны. ;-)
Потом, глядя на название функции
myFile := OpenFile("test.txt", ReadWrite)
вы не можете понять что же она делает.

А если это handle := open(name, mode) ?


№ 3713   07-04-2007 12:13 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3711« (Geniepro)
___________________________
You beat me to it :)
Что интересно, Руслан думал, что типа щас сьязвит. :))
Вот она зашоренность. Некоторые вещи даже не оспариваются, воспринимаются как данность. В данном случае строгая типизация однозначно связывается с необходимостью явно указывать типы во всех случаях.
По другому ведь и быть не может. :))


№ 3712   07-04-2007 12:09 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3709« (Руслан Богатырев)
___________________________
:))) Руслан, вы прекрасно кстати справились с описанием type inference? то есть автоматического выведения типов.
Вправда в первом пункте сделали ошибку. Но пункты 2 и 3 - правильные.
А пункт первый я вам щас подправлю:

O: Без объявления тип переменной непонятен.
Н: Чушь, тип переменной в подавляющем большинстве случаев однозначно проистекает от опереации над ней производимой.



№ 3711   07-04-2007 12:08 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3709« (Руслан Богатырев)
___________________________

Обязательное объявление типа переменной - Необязательное объявление типа переменной

O: Без объявления тип переменной непонятен.
O: Без объявления не знаешь, каков тип переменной
O: Без объявления непонятно, какой из двух (трех, десяти) типов для переменной используется.

H: Чушь. Автоматический вывод типов нам поможет! :о))


Н: Да, тут объявление нужно. И мы им пользуемся. Но таких случаев считанные проценты, по сравнению с ситуациями, когда тип без объявления определяется однозначно.

А это да, такое иногда бывает, когда среда разработки во время написания тела новой функции начинает париться и отказываться предлагать code-complition (в F# с таким столкнулся)... ;о)


№ 3710   07-04-2007 12:04 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3708« (Jack Of Shadows)
___________________________
Если смотреть на схему именования, как она принята при неквалиф. импорте, то простое "дописывание" имени модуля может и правда делать код громоздким. Потому что само имя, к примеру, класса, уже включает в себя информацию о том, что он за птица...
Если язык с обязательной квалификацией, то семантика названия не дублируется именем модуля, а наоборот - делится на две части. Так же, как имя каталога и имя файла.

Пример - в ББ графика построена на схеме Model-View-Controller. Я пишу новый графический объект. У него будет View, Model и Controller. Я не буду называть эти типы MyEditorView, MyEditorModel и MyEditorController, как это было бы принято в Дельфи, например. Я их прямо так и назову - View, Model и Controller. Помещаю их в модуль MyEditor, к примеру.

Затем использую именование MyEditor.View, MyEditor.Model, MyEditor.Controller.
И в среде десятки других типов с точно такими же названиями. Название типа всего лишь определяет техническое назначение: "гайка", "шайба", "винт". А название модуля определяет тот компонент, к которому та или иная "гайка" относится. Чем плохо?

А вот дельфистов, которые восстают против полной квалификации, я на самом деле понимаю. Поскольку язык допускает и поощряет Н-схему, то любой разработчик компонента не может себе позволить именовать типы по вышеописанному принципу, он думает - а что, если имена совпадут? - и, естественно, дублирует имя компонента в названии класса: MyEditorView... Если учесть, что везде и всюду в существующем коде УЖЕ все названо по такому принципу, то потребовать от программистов писать MyEditor.MyEditorView - это громоздко и неудобно...
Дельфистов-то понять можно, но вот компанию Борланд, и компанию Микрософт, в Шарпе заботливо разложившую такие же "грабли" понять сложно...


№ 3709   07-04-2007 11:48 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3708« (Jack Of Shadows)
___________________________

:)

Обязательное объявление типа переменной - Необязательное объявление типа переменной

O: Без объявления тип переменной непонятен.
Н: Чушь, смысл кода в применении сущностей, а не в том чья это переменная

O: Без объявления не знаешь, каков тип переменной
H: Чушь, вы не ищете тип КАЖДОЙ переменной, на которую смотрите. Для того они и созданы, чтобы вы не отвлекались на нижний уровень абстракции каждый раз. А в тех РЕДКИХ (по сравнению с чтением названия переменных) случаях, когда вам надо прочитать и тип переменной, прекрасно справляется "костыль" в виде IDE

O: Без объявления непонятно, какой из двух (трех, десяти) типов для переменной используется.
Н: Да, тут объявление нужно. И мы им пользуемся. Но таких случаев считанные проценты, по сравнению с ситуациями, когда тип без объявления определяется однозначно.

Ну а дальше выбор конкретного лагеря уж пусть каждый делает для себя сам.

P.S. Мои глубочайшие извинения за вынужденный плагиат.


№ 3708   07-04-2007 11:36 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3707« (Руслан Богатырев)
___________________________
Обязательный квалификатор - Необязательный квалификатор

O: Без квалификатора код непонятен.
Н: Чушь, смысл кода в применении сущностей, а не в том откуда импортированы эти сущности

O: Без квалификатора не знаешь где искать код функции
H: Чушь, вы не читаете код КАЖДОЙ функции на которую смотрите. Для того они и созданы, чтобы вы не отвлекались на нижний уровень абстракции каждый раз. А в тех РЕДКИХ (по сравнению с чтением названия функции) случаях когда вам надо прочитать и код функции, с прыжком в ее тело прекрасно справляется "костыль" в виде IDE

O: Без квалификатора непонятно какая из двух (трех, десяти) функций вызывается.
Н: Да, тут квалификатор нужен. И мы им пользуемся. Но случаев функций с одинаковыми именами считанные проценты, по сравнению с функциями, чье имя определает их однозначно.

Ну а дальше выбор конкретного лагеря уж пусть каждый делает для себы сам.



№ 3707   07-04-2007 11:27 Ответить на это сообщение Ответить на это сообщение с цитированием
Ответ на »сообщение 3701« (AVC)
___________________________

Не слишком логично, IMHO, использовать строгий язык (Паскаль), а в местах межмодульных соединений от этой строгости вдруг отказываться и полагаться на "авось". :)

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

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


<<<... | 3726—3717 | 3716—3707 | 3706—3697 | ...>>>
Всего сообщений в теме: 6256; страниц: 626; текущая страница: 255


Добавить свое сообщение

Отслеживать это обсуждение

Дополнительная навигация:
Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру
  
Время на сайте: GMT минус 5 часов

Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
Функция может не работать в некоторых версиях броузеров.

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования