freepascal.ru

какая же должна быть типизация у идеала?
и почему

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

Для разных языков разные требования. Есть языки с жесткой типизацией, как C++ или Pascal, а есть языки с более мягкой типизацией и возможностью преобразования типов в зависимости от контекста, такие, как Perl или PHP.

Неудобно бывает и там, и там. Паскалю не хватает простого преобразования типов друг в друга, тогда как в PHP иногда приходится принудительно указывать тип, чтобы не отдавать преобразование на милость транслятору.

Generic решает часть проблем, но лишь для сходных типов и в compile-time. А хотелось бы простого преобразования не только чисел друг в друга, но и чисел в строки и наоборот, записей в строки и т.п.

Например, так:

Код: Выделить всё

program cast;
var
  s: string;
  i: integer;
  r: real;
begin
  s := '578'; //комментарии излишни
  (string) r := s + '.5'; //r = 578.5
  i := 10 + (integer) s; //i = 588
  i := (integer) (r + i + 0.5); //i = 579 + 588, посчитайте, мне влом, но там целое число
end.


Я считаю что и простые типы должны быть объектами, т.е. иметь набор методов. Тогда реализуя метод __convert__(toType) (подчеркивания я взял из Python) можно описать преобразование любого типа в любой. Что касается синтаксиса преобразования, то S := String(1 + 2), я считаю более приемлемым. Что бы переопределить методы стандарных типов, должны присутствовать механизмы динамичекского переопределения, либо статического, но тогда потребуются дополнительные директивы. Возможно тут помогут метаклассы (метатипы .

..bw

а что это никто не предлагает вообще убрать объявление переменных?
неужели нет поклонников такого подхода?

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

насчёт типизации
я периодически пинаю рзработчика IBExpert-а
он реализовал своё подмножество диалекта языка в IBEblock - очень не хватает именно таких мелких зашит от дурака. Он сопротиваляется
также предлагал ему сделать эелементарнийшую проверку - нельзя использовать не проинициализированную переменную - тоже не подержал
хотя 2 этих органичения очень сильно облегчают отладку и поиск глюков.

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

> но стоит заметить, что ошибки искать гораздо сложнее
Это не проблема.

..bw

Я считаю что и простые типы должны быть объектами, т.е. иметь набор методов. Тогда реализуя метод __convert__(toType) (подчеркивания я взял из Python) можно описать преобразование любого типа в любой.

Удобно, согласен. Но есть недостатки. Мы тогда лишимся низкоуровневых типов, в которых нужно хранить биты и данные, структуру которых мы знаем, по крайней мере, для данной машины. Паскаль, все-таки, не настолько высокоуровневый язык. Даже в Яве, помимо классов-типов, оставили примитивные типы. А тут паскаль - компилируемый язык, который должен подходить и для системного программирования, где нам нужен полный контроль за структурой, вплоть до бита.

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

Что касается синтаксиса преобразования, то S := String(1 + 2), я считаю более приемлемым.

Согласен, паскаль, все ж таки. Это я по аналогии с РНР так скобки расставил, для примера. А вообще, тут я согласен с тобой.

а что это никто не предлагает вообще убрать объявление переменных?

В РНР есть область видимости и существования, регулируемая вплоть до блока операторов. Если я создал переменную в цикле, я могу быть уверен, что за пределами цикла переменной не будет.

Более того, есть конкретные рекомендации, которые, при их несоблюдении выливаются в Warning'и, говорящие о том, что перед использованием любая переменная должна быть объявлена путем присвоения ей начального значения.

Примерно такой же подход реализован в С++, но там переменные объявляются с указанием типа.

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

В РНР есть область видимости и существования, регулируемая вплоть до блока операторов. Если я создал переменную в цикле, я могу быть уверен, что за пределами цикла переменной не будет.

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

> Мы тогда лишимся низкоуровневых типов
Не лишимся. Сейчас все операции над встроенными (простыми) типами тоже выполняется машинным кодом (размещенным непосредственно в потоке кода или вынесенным в функции). Та же самая __convert__ будет выполнять операции конвертации из простого типа с которым она "сопоставленна". Возможно в Run-Time потребуются дополнительные структуры, которые будут описывать этот тип, хотя это не обязательно. А вот экземпляр этот простого типа останется точно таким же (RTTI и прочего не будет), т.е. все операции над типом предопределяются во время компиляции. SizeOf же безболезненно используется над типом Integer и размер переменной Integer от существования такой функции не изменился. Точно так же размер Integer не изменится, если компилятор в нужном месте подставит вызов (и заменит его на машинный код):

Код: Выделить всё

var
  I: Integer;
  S: String;
begin
  I := 12;
  S := '__' + I + '__'; {S := '__' + I.__convert__(String) + '__';}


..bw

По поводу "убрать объявления переменных" история показала, что это путь ведущий к ошибкам. Вспомните Basic, ведь там именно так и было, точнее объявления были неявными. Но впоследствии пришлось ввести дополнительную опция, требующую явно объявлять переменные.
И ошибки вследствии неявного объявления хоть и детские, но как ни странно их совершают не только начинающие, но и матёрые зубры программирования. А уж для тех кто начинает программировать, особенно самостоятельно, это и вообще иногда неразрешимая проблема.
А типизация больше нужна компилятору и, как ни странно, пользователю, чем программисту. Программисту проще использовать один универсальный тип без заморочки с его преобразованием. Но, есть как всегда но... Если компилятор (или run-time блок) начнёт сам преобразовывать типы к нужному виду, то не всегда он выдаёт то, что нужно. Да и время лишнее затрачивается.
Вот если бы изобрести универсальный тип, который вообще не нужно было бы никуда конвертировать...

Vadim писал(а):Вот если бы изобрести универсальный тип, который вообще не нужно было бы никуда конвертировать...

строки
набор процедур для выполнения арифметики без преобразования к цичслам уже сейчас есть
PS
типизация нужна - однозначно

alexs
Это я понимаю, что строки.
Ведь мы сами читаем абстрагированиое изложение информации именно в виде строк. А вот как потом происходят вычисления - никто не знает.

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

Я полагаю, что преобразование идёт внутри интерпретатора или добавляется компилятором в виде run-time кода.
А вот когда компьютер будет хранить у себя и обрабатывать информацию именно как строки, вот тогда да...

Vadim писал(а):А вот когда компьютер

Ты хотел сказать процессор?

alexs
Нет, именно компьютер.
Ведь процессор без остальных запчастей, работающих так же как и процессор, нам не нужен? Или я ошибаюсь?