Зачем два механизма ограничений?

Проектирование и разработка идеального средства программирования.

Модератор: Модераторы

Пожалуйста, прочтите верхний пост, и скажите какой подход к дизайну языка лучше.

Лучше как сейчас
10
53%
Лучше так, как сейчас, и никак иначе!
2
11%
Лучше без private и strict (но с остальными секциями)
4
21%
Мне пофиг
1
5%
Лучше убрать interface и implementation
2
11%
 
Всего голосов : 19

Re: Зачем два механизма ограничений?

Сообщение vitaly_l » 26.10.2015 00:18:10

Kemet писал(а):Так они уже созданы - Модула-2, Модула-3, Оберон-2, Активный Оберон...

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


Пришёл к выводу, что, та часть предлагаемого нововведения которая мне понравилась, на самом деле - усложняет чтение кода.
В частности, когда открываю модуль, я всегда могу вверху просмотреть, как рубрикатор/оглавление в книге - названия всех функций и выбрать нужную. Как правило они умещаются на экране или чуть больше...
А в нововведении такой возможности нет... там сразу будет идти код, и это неудобно, т.к. невозможно увидеть весь список и одним кликом перейти к нужной. И придётся листать модуль... А если модуль длинный... то...

И второй, минус, то что, приват и паблик функции идут не подряд, а разделены. Это опять, таки неудобно, т.к. иногда я их ставлю рядом, когда готовлю одновременно: приватную и публичную. А в нововведении, их рядом поставить нельзя, соответственно - это создаёт массу проблем при программировании.

Третий минус, если в unit-модуле будет несколько объектов, и код всех разбит на две части - то это опять создаёт трудности в чтении модуля.

Если такая схема ОБЯЗАТЕЛЬНА в Модуле-3 и Обероне, то они мне априори не нравятся как языки, т.к. существующая сейчас в паскале конструкция - лучше и удобнее с точки зрения читабельности кода и программирования.


.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Зачем два механизма ограничений?

Сообщение sts » 26.10.2015 00:26:45

эх, регулярно возникает потребность в предлагаемом/похожем механизме "продолжения" объявления класса в секции implementation.
но судя по уровню исходной продуманности ObjectPascalя, авторы наверняка думали над этим, вот чтото их остановило.

скалогрыз писал(а):Аха! Вот нашёл подводный каменть для вынесения private секции в implementation.

нормально, можно поступить также как при предварительном объявлении типов
так сказать предварительное объявление свойств
Последний раз редактировалось sts 26.10.2015 00:30:00, всего редактировалось 1 раз.
sts
постоялец
 
Сообщения: 406
Зарегистрирован: 04.04.2008 12:15:44
Откуда: Тольятти

Re: Зачем два механизма ограничений?

Сообщение скалогрыз » 26.10.2015 00:29:04

vitaly_l писал(а):А в нововведении такой возможности нет... там сразу будет идти код, и это неудобно, т.к. невозможно увидеть весь список и одним кликом перейти к нужной. И придётся листать модуль... А если модуль длинный... то...

Считаю, что ключевое слово здесь кликом перейти.
IDE для тебя "визуально склеит" обе части и в древе объектов вместе их покажет.

vitaly_l писал(а):И второй, минус, то что, приват и паблик функции идут не подряд, а разделены. Это опять, таки неудобно, т.к. иногда я их ставлю рядом, когда готовлю одновременно: приватную и публичную. А в нововведении, их рядом поставить нельзя, соответственно - это создаёт массу проблем при программировании.

Ставить их рядом можно. Ибо измнение обратно совместимое. Т.е. если хочешь - можешь описывать private секцию в interface-е. Запрета нет. Зато если у тебя privatе секция вдруг окажется больше, чем один экран (посмотри классы, скажем в LCL), то захочется их убрать из interfacа модуля. Т.к. они особо не помагают, ибо приватные, и другими модулями использоваться не могут.

vitaly_l писал(а):Третий минус, если в unit-модуле будет несколько объектов, и код всех разбит на две части - то это опять создаёт трудности в чтении модуля.

код как раз не разбит на две части. Код всегда находится только в implementation-е. Не Си(++/шарпы) знаете ли.
Неважно, где объявлен метод объявлен в interface- или в implementation-е - код для метода всегда только в Implementation-е

Добавлено спустя 11 минут 39 секунд:
sts писал(а):нормально, можно поступить также как при предварительном объявлении типов
так сказать предварительное объявление свойств

Придётся "задабривать" парсер, и делать его менее требовательным к объявлению пропертей.
Осталось только одна проблема, это заполнение VMT.
В частности - размер instance-а класса.

Что интересно, компилятор даже позволяет определить класс дважды в interface и implementation-е.
Конечно, на данный момент о ругнётся, мол "duplicated identifier", но в целом, код FPC весьма и весьма дружественен в "до-определению".
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Зачем два механизма ограничений?

Сообщение vitaly_l » 26.10.2015 00:43:17

скалогрыз писал(а):код как раз не разбит на две части. Код всегда находится только в implementation-е. Не Си(++/шарпы) знаете ли.
Неважно, где объявлен метод объявлен в interface- или в implementation-е - код для метода всегда только в Implementation-е

И что??? В Implementation - то он разбит на две части, которые могут находится на расстоянии километра друг от друга... Это неудобно! Или удобно?

Добавлено спустя 8 минут 26 секунд:
Более того получается модуль в коде разбит на три части... т.к. есть ещё объявление куска объекта в interface...

Но всё равно смертельного ничего в новшестве не будет... потом добавим BEGIN CLOSE END; вместо try finnaly end и этим сохраним лучшее от Модулы и Оберрона в Паскале. Что в общем-то хорошо, т.к. расширяет, а не сужает возможности Паскаля!


.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Зачем два механизма ограничений?

Сообщение скалогрыз » 26.10.2015 01:00:04

vitaly_l писал(а):И что??? В Implementation - то он разбит на две части, которые могут находится на расстоянии километра друг от друга... Это неудобно! Или удобно?

они находятся на расстоянии километра друг от друга, только в том случае если ты их напишешь на расстоянии километра друг от друга.

vitaly_l писал(а):более того получается модуль в коде разбит на три части... т.к. есть ещё объявление куска объекта в interface...

да, это так.
1) объявление в интерфейса
2) объявление private в implementation - потенциально она может дублировать и все public / protected методы (если их объявление не противоречит интерфейса), просто для (не)удобства программиста.
3) собственно код
но 2 и 3 идут рука об руку, а 1ое диктует что и как использовать

Код: Выделить всё
interface
type
  TMyClass = class(TObject)
  public
    procedure Connect;
    procedure SendMessage(const msg: string);
    procedure Disconnect;
    property Host: string read write
    property NickName: string read write;
  end;

implementation

uses
  NetworkSockets;

type
  TMyClass = class(TObject)
  private
    fSocket : TNetworkSocket;
    fHost : string;
    fNickName : string;
    procedure SetHost(const Ahost: string);
    procedure SetNickName(const Anickname: string);
  public
    property Host: string read fHost write SetHost;
    property NickName: string read fNickName write SetNickName;
  end;

procedure TMyClass.Connect;

procedure TMyClass.SendMessage(const msg: string);

procedure TMyClass.Disconnect;

procedure TMyClass.SetHost(const Ahost: string);

procedure TMyClass.SetNickName(const Anickname: string);

скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Зачем два механизма ограничений?

Сообщение vitaly_l » 26.10.2015 01:05:15

скалогрыз писал(а):но 2 и 3 идут рука об руку, а 1ое диктует что и как использовать

Ну лиса.... ну хитёр... Художников не проведёшь!!!!
Вот авторский топик стартера код, помноженный на "километр"
Код: Выделить всё
unit MyUnit;

interface

type
TMyObject = object
  procedure MyPublicMethod;
end;

implementation

type
TMyObject = object
  X: Integer;
  procedure MyPrivateMethod;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod1;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod2;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod3;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod4;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod5;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod6;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod7;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod8;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod9;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod99;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod999;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod9999;
  begin
    X := 5;
  end;
  procedure MyPrivateMethod99999;
  begin
    X := 5;
  end;
  // это пример вынесения определения за секцию объекта
  procedure MyPublicMethod; forward;
end;

procedure TMyObject.MyPublicMethod;
begin
  MyPrivateMethod;
end;

end.


Удобно???? редактировать TMyObject.MyPublicMethod????? когда они на расстоянии километра???


.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Зачем два механизма ограничений?

Сообщение скалогрыз » 26.10.2015 01:20:30

vitaly_l писал(а):Вот авторский топик стартера код, помноженный на "километр"

у тебя неправильное умножение. попробуй ещё раз.

...А нифига. Умножение правильно, но кажется Дож немного синтаксис не соблюдает.

Ожидаемый результат
Код: Выделить всё
    unit MyUnit;

    interface

    type
    TMyObject = object
      procedure MyPublicMethod;
    end;

    implementation

    type
    TMyObject = object
      X: Integer;
      procedure MyPrivateMethod;
      procedure MyPrivateMethod1;
      procedure MyPrivateMethod2;
      procedure MyPrivateMethod3;
      procedure MyPrivateMethod4;
      procedure MyPrivateMethod5;
      procedure MyPrivateMethod6;
      procedure MyPrivateMethod7;
      procedure MyPrivateMethod8;
      procedure MyPrivateMethod9;
      procedure MyPrivateMethod99;
      procedure MyPrivateMethod999;
      procedure MyPrivateMethod9999;
      procedure MyPrivateMethod99999;
      // это пример вынесения определения за секцию объекта
      procedure MyPublicMethod; forward;
    end;

    procedure TMyObject.MyPublicMethod;
    begin
      MyPrivateMethod;
    end;

    procedure TMyObject.MyPrivateMethod;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod1;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod2;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod3;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod4;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod5;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod6;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod7;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod8;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod9;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod99;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod999;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod9999;
    begin
      X:=5;
    end;

    procedure TMyObject.MyPrivateMethod99999;
    begin
      X:=5;
    end;

end.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Зачем два механизма ограничений?

Сообщение vitaly_l » 26.10.2015 01:27:39

скалогрыз писал(а):Дож немного синтаксис не соблюдает

Тогда другой разговор, если речь, о возможности описывать объект в implementation, но там будут сохранены все возможности interface - то вообще непонятно почему это нельзя сейчас? Но общую логику - это ломает, т.к. объект тогда можно разбить на 10-ть частей... И возможно для автора это удобно, а вот для прочтения не автором усложняет, т.к. он не знает из 5 или 55 частей состоит объявление объекта?


.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Зачем два механизма ограничений?

Сообщение скалогрыз » 26.10.2015 01:30:58

vitaly_l писал(а):Но общую логику - это ломает, т.к. объект тогда можно разбить на 10-ть частей... И возможно для автора это удобно, а вот для прочтения не автором усложняет, т.к. он не знает из 5 или 55 частей состоит объявление объекта?

тут есть два подхода к проблеме.
1) С правильным автором, и правильным объектом, важна только одна часть - interface. Всё остальное кухня, и уж сам автор решает. Хотя ничто не мешает ограничить implementation объявление лишь 1-ним разом.

2) С неправильным автором, где приходится отлаживать объект, стороний разработчик всё-равно имеет в руках весь модуль и без труда сможет найти их 1ой или нескольких частей состоит объект.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Зачем два механизма ограничений?

Сообщение vitaly_l » 26.10.2015 01:43:17

скалогрыз писал(а):С правильным автором, и правильным объектом, важна только

Придумал, как можно объединить и работать как мне удобно... Ненужно выносить тело функций за секцию объекта, и тогда они все помещаются между class end; и там с ними можно делать всё что угодно... И объявления приватных функций тогда ненужны... остаются только паблик в интерфейсе. Тогда всё встаёт на свои места и снова удобно для программирования. Можно внедрять... художники дают добро... :roll: <== юмор...
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Зачем два механизма ограничений?

Сообщение скалогрыз » 26.10.2015 02:12:39

vitaly_l писал(а):Ненужно выносить тело функций за секцию объекта, и тогда они все помещаются между class end; и там с ними можно делать всё что угодно...

как раз то, что Дож использовал в своём примере.
Только это для Паскаля не работает. Т.к. принцип паскала: "сначала объявить, потом использовать".
По-этому класс сначала должен быть объявлен до своего end-а, а потом уже писать реализацию его методов.
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Зачем два механизма ограничений?

Сообщение vitaly_l » 26.10.2015 02:17:59

Но тогда нет и смысла в секции interface и implementation, а равно и в первом объявлении объекта, т.к. всё можно уместить в одном объекте. А именно: если для функции есть паблик объявление, то на паблик, а если нет то приват. Соответственно можно сделать ещё более удобное сокращение, примерно такое:

Код: Выделить всё
unit MyUnit;
// ненужен => interface
// никаких объявлений в интерфейсе
// ненужен тоже => implementation
// сразу идёт ВЕСЬ объект в одном флаконе, а при желании можно вынести за тело объекта
type
TMyObject = object
  X: Integer;

  public
    Y: Integer;
    procedure MyPublicMethod;
  end; // end public
  protected
    Z: Integer;
    procedure MyProtectedMethod;
  end; // end protected


  procedure MyPrivateMethod;
  begin
    Y := 5;
  end;


  procedure MyProtectedMethod;
  begin
    X := 5;
  end;


  procedure MyPublicMethod;
  begin
    Z := 5;
  end;
end;

  // это пример вынесения определения за секцию объекта
procedure TMyObject.MyPublicMethod2;
begin
  MyPrivateMethod;
end;

end.


Соответственно полное избавление от interface, implementation и объект получается компактный в одном флаконе. (при желании можно часть вынести за тело "флакона"). Заметьте, что так появляется возможность добавлять Y и Z переменные ЛЮБОГО из: protected, published, private, public, strict private, strict public...


.
Последний раз редактировалось vitaly_l 26.10.2015 17:28:35, всего редактировалось 1 раз.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Зачем два механизма ограничений?

Сообщение скалогрыз » 26.10.2015 02:59:58

vitaly_l писал(а):Соответственно можно сделать ещё более удобное сокращение, примерно такое:
...
Соответственно полное избавление от interface, implementation и объект получается компактный в одном флаконе. (при желании можно часть вынести за тело "флакона"). Заметьте, что так появляется возможность добавлять Y и Z переменные ЛЮБОГО из: protected, published, private, public, strict private, strict public...


если ты заменишь begin на { , а end на } то как раз получишь C#
скалогрыз
долгожитель
 
Сообщения: 1803
Зарегистрирован: 03.09.2008 02:36:48

Re: Зачем два механизма ограничений?

Сообщение Mirage » 26.10.2015 03:45:58

скалогрыз писал(а):Новые языки обречены на жалкое существование, ибо с Сями (их долгими библиотеками) уже мало что может потягаться. Обратная совместимость и забота о существующих библиотеках стоят на первом месте. По-этому навороты приходят в "старые" языки, превращая их в монстров!


Для JVM эта проблема решается совместимостью на уровне .class файлов. Т.е. программу можно одновременно писать на нескольких языках, что нередко и делается.
В .NET, наверное тоже, если конечно, там что-то еще используется, помимо C#.
Вообще забавно, .NET изначально многоязычная, а JVM моноязычная, однако вышло практически наоборот...

В случае же нового Паскаля просто должна быть односторонняя совместимость на уровне .ppu. Т.е. новый язык сможет использовать существующие библиотеки.

Проблема больше в том, что разработка языка дело непростое и заниматься им особо некому. Да и к консенсусу прийти у сообщества вряд ли получится.

С другой стороны это давно назрело. Вон, даже Эппл язык обновила, хотя им-то зачем непонятно.
Mirage
энтузиаст
 
Сообщения: 881
Зарегистрирован: 06.05.2005 20:29:07
Откуда: Russia

Re: Зачем два механизма ограничений?

Сообщение Снег Север » 26.10.2015 09:11:55

Mirage писал(а):В .NET, наверное тоже, если конечно, там что-то еще используется, помимо C#.

Такое впечатление, что о программировании в .NET вы только в газетах читали... Для .NET полно кода на Бейсик.нет и на С++ для .NET, это как минимум.
Аватара пользователя
Снег Север
долгожитель
 
Сообщения: 2993
Зарегистрирован: 27.11.2007 16:14:47

Пред.След.

Вернуться в Компилятор / язык программирования

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5

Рейтинг@Mail.ru