Область видимости переменных

rsn81

До поры до времени полагал, что в ABAP чтит кодекс области видимости переменных, постепенно понял, что избирательно... только в пределах подпрограмм.

Например.

Цитата:

do 5 times.
data d type i value 0.
d = d + 1.
write:/ d.
enddo.

Соответствующая интерпретация на любом С++-подобном языке выдаст в консоль пять раз 1, в то время как ABAP числа от 1 до 5. То есть по факту в Сишном понимании, ABAP компилирует этот код в нечто подобное:

Цитата:

data d type i value 0.
do 5 times.
d = d + 1.
write:/ d.
enddo.

OK, делаем вывод: ABAP в пределах подпрограммы работает с переменными аналогично Pascal - все переменные глобально видимы.

Но остается без ответа вопрос: а на кой тогда давать возможность объявления переменной в любом месте подпрограммы (Pascal же не зря не дает такой возможности), если это не играет рояли? :-)

vga

rsn81 написал(а):

До поры до времени полагал, что в ABAP чтит кодекс области видимости переменных, постепенно понял, что избирательно... только в пределах подпрограмм.

В хелпе четко прописано о области видимости. К операторам это не относится.

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

В языке С переменные описываются в начале программы. Иначе компилятор выдаст ошибку.

Сергей Королев

Про соответствие ABAP общепринятым стандартам лучше умолчать

Думаю, при авторы компилятора ABAP были вообще не особо в курсе существования теорий синтаксического разбора да и вообще других языков...

sy-uname

rsn81 написал(а):

До поры до времени полагал, что в ABAP чтит кодекс области видимости переменных, постепенно понял, что избирательно... только в пределах подпрограмм.

Что значит избирательно в данном контексте? Область видимости и действия переменных вполне себе документирована, какой ещё нужен "кодес"? Тем более что "кодекс - это не закон ..." (с) Пираты ...

rsn81 написал(а):

...OK, делаем вывод: ABAP в пределах подпрограммы работает с переменными аналогично Pascal - все переменные глобально видимы.

Разве в паскале уже отменили блок BEGIN END; который образует собственную облась видимости для объявленых в нём переменных? Или я что-то с чем-то путаю???

rsn81 написал(а):

Но остается без ответа вопрос: а на кой тогда давать возможность объявления переменной в любом месте подпрограммы (Pascal же не зря не дает такой возможности), если это не играет рояли? :-)

Не играет?
Попробуйте зыпустить репорт с такой конструкцией

Code:

  DO 5 TIMES.
    d = d + 1.
    DATA d TYPE i VALUE 0.
    WRITE:/ d.
  ENDDO.

ArmAnn

sy-uname написал(а):

Разве в паскале уже отменили блок BEGIN END; который образует собственную облась видимости для объявленых в нём переменных? Или я что-то с чем-то путаю???

путаете

разве что в Дельфи такая возможность со временем появилась, и то сомнительно

rsn81

Сергей Королев написал:

Про соответствие ABAP общепринятым стандартам лучше умолчать

Думаю, при авторы компилятора ABAP были вообще не особо в курсе существования теорий синтаксического разбора да и вообще других языков...

Ага.

Мне еще нравится заплатка ООП на ABAP: после copy-paste обычного 100% исполняемого ABAP-интерпретатором кода из подпрограммы в метод класса начинается ругань а-ля "данный оператор недоступен в ОО-контексте". Даже и лекарство для заплатки нашлось: оформляешь строчку нелюбимого объектами в исполнении ABAP кода в подпрограммку и ставишь вызов из метода объекта - все, ABAP жестоко обманут и уже не ругается.

sy-uname написал(а):

Разве в паскале уже отменили блок BEGIN END; который образует собственную облась видимости для объявленых в нём переменных? Или я что-то с чем-то путаю???

Не знаю, что с чем вы путаете. Выше собственно и было сказано, что область видимости переменных ABAP аналогична Pascal. Одно только непонятно, на кой-то ляд сделано допущение: объявление переменной в любом месте программы. Наверно самое разумное объяснение, как и заметили выше, улучшение читаемости кода. Гм... только что-то в эффективность этого вериться с трудом.

sy-uname написал(а):

Не играет?
Попробуйте зыпустить репорт с такой конструкцией

Это, вообще говоря, чести ABAP не добавляет, даже наоборот. :-)

Собственно к области видимости это отношения не имеет, а говорит только о том, что интерпретатор проходит по программе за один ход.

Пономарев Артем

Не нужно сомневаться

Есть и давным-давно была в Delphi возможность объявлять локальные переменные в процедурах и функциях.
А вот такая конструкция:

Code:

  DO 5 TIMES. 
    d = d + 1. 
    DATA d TYPE i VALUE 0. 
    WRITE:/ d. 
  ENDDO. 

в дельфях не пройдет.

sy-uname

rsn81 написал(а):

Мне еще нравится заплатка ООП на ABAP: после copy-paste обычного 100% исполняемого ABAP-интерпретатором кода из подпрограммы в метод класса начинается ругань а-ля "данный оператор недоступен в ОО-контексте". Даже и лекарство для заплатки нашлось: оформляешь строчку нелюбимого объектами в исполнении ABAP кода в подпрограммку и ставишь вызов из метода объекта - все, ABAP жестоко обманут и уже не ругается.

Почему обманут - выполнение программы вышло из области действия ООП и выполняется в классическом окружении - так в чём тут обман?

Цитата:

... Одно только непонятно, на кой-то ляд сделано допущение: объявление переменной в любом месте программы. Наверно самое разумное объяснение, как и заметили выше, улучшение читаемости кода. Гм... только что-то в эффективность этого вериться с трудом.

Да-да, только вот с С++ возможность объявлять переменные там где нужно а не в начале блока преподносилось как громадное достижение в сравнении с классическим С.

Цитата:

Это, вообще говоря, чести ABAP не добавляет, даже наоборот. :-)

Собственно к области видимости это отношения не имеет, а говорит только о том, что интерпретатор проходит по программе за один ход.

C++ то-же видать однопроходный, раз требуется объявлять переменные до первого использования.

rsn81

sy-uname написал(а):

Почему обманут - выполнение программы вышло из области действия ООП и выполняется в классическом окружении - так в чём тут обман?

Потому что замена такого кода:

Цитата:

class SomeObject implementation.
method someMethod.
<someAction>. "здесь при компиляции упомянутая ошибка
endmethod.
endclass.

на такой:

Цитата:

class SomeObject implementation.
method someMethod.
perform someForm.
endmethod.
endclass.

form someForm.
<someAction>. "а так все OK
endform.

абсолютно ничего не меняет с точки зрения логики, но почему-то помогает съесть ABAP-у желаемую логику кода в ООП-исполнении. Завтра с работы смогу показать такие примеры, если, конечно, интересно.

sy-uname написал(а):

Да-да, только вот с С++ возможность объявлять переменные там где нужно а не в начале блока преподносилось как громадное достижение в сравнении с классическим С.

Честно говоря, не понял, о чем вы.

sy-uname написал(а):

C++ то-же видать однопроходный, раз требуется объявлять переменные до первого использования.

Во-первых, C++ - компилятор, а ABAP, если не ошибаюсь, интерпретатор. Во-вторых, не понимаю, что вы хотите доказать.

Начали с того, что порядок инициализации переменных в коде программы обычно играет роль в ЯП, кроме а-ля Pascal, где достаточно логичный синтаксис прединициализации переменных. Нашли, что в ABAP порядок инициализации переменных роли не играет. Вы указали на то, что с ABAP-ом все еще плачевнее: как только интепретатор добирается до объявления переменной он делает ее в глобально-видимой (в пределах подпрограммы), казалось бы, остался один шаг до Pascal - сделай интерпретатор первый проход по коду подпрограммы для сбора всех объявлений переменных, а только после этого проход для выполнения кода - и приведенный вами пример исполнится. Так нет же... :-)

sy-uname

rsn81 написал(а):

Потому что замена такого кода:
... на такой: ... абсолютно ничего не меняет с точки зрения логики, но почему-то помогает съесть ABAP-у желаемую логику кода в ООП-исполнении. ...

Потому что в целях совместимости и сохранения работоспособности старых программ в новых реализациях ABAP более жёсткие требования к описаниям и манипуляциям с типами|данными распространяются (_пока_) только на новую функциональность.

часть

sy-uname написал(а):

rsn81 написал(а):

Потому что замена такого кода:
... на такой: ... абсолютно ничего не меняет с точки зрения логики, но почему-то помогает съесть ABAP-у желаемую логику кода в ООП-исполнении. ...

Потому что в целях совместимости и сохранения работоспособности старых программ в новых реализациях ABAP более жёсткие требования к описаниям и манипуляциям с типами|данными распространяются (_пока_) только на новую функциональность.

кстати, еще одна недопустимость использования в ОО контексте - нельзя создавать внутренние таблицы с header line... Никто не знает, почему?

sy-uname

rsn81 написал(а):

...
Начали с того, что порядок инициализации переменных в коде программы обычно играет роль в ЯП, кроме а-ля Pascal, где достаточно логичный синтаксис прединициализации переменных. Нашли, что в ABAP порядок инициализации переменных роли не играет. Вы указали на то, что с ABAP-ом все еще плачевнее: как только интепретатор добирается до объявления переменной он делает ее в глобально-видимой (в пределах подпрограммы), казалось бы, остался один шаг до Pascal - сделай интерпретатор первый проход по коду подпрограммы для сбора всех объявлений переменных, а только после этого проход для выполнения кода - и приведенный sy-uname-ом пример исполнился. Так нет же... :-)

Замечу что компилятор всё-таки контролирует соответствие количества передаваемых параметров и их типы на момент компиляции - так что однозначно утверждать о тольео одном проходе я-бы не стал.

По поаоду деклараций пересенных:

Code:

class Hello2  {  
   public static void main ( String args[] ) {  
      int i = 3; 
      System.out.println ( i ); 
   } 
}

Цитата:

>javac Hello2.java

>java Hello2
3

Code:

class Hello2  {  
   public static void main ( String args[] ) {  
      System.out.println ( i ); 
      int i = 3; 
   } 
}

Цитата:

>javac Hello2.java
Hello2.java:3: cannot resolve symbol
symbol : variable i
location: class Hello2
System.out.println ( i );
^
1 error

Вроде Java не самый из "неправильных" языков

rsn81

часть написал(а):

кстати, еще одна недопустимость использования в ОО контексте - нельзя создавать внутренние таблицы с header line... Никто не знает, почему?

Именно.

Тоже пришлось найти обходной маневр.

sy-uname

часть написал(а):

кстати, еще одна недопустимость использования в ОО контексте - нельзя создавать внутренние таблицы с header line... Никто не знает, почему?

Потому что под одним именем скрыты два разных объекта - структура и таблица, что пораждает потециально небезопасный код - классический случай когда передают таблицу вместо структуры или наоборот. Или, что ещё хуже используют следующий изврат:

Code:

form _form tables itab.
    itab-field1 = some_value1.
    itab-field2 = some_value2.
endform.

rsn81

sy-uname написал(а):

Замечу что компилятор всё-таки контролирует соответствие количества передаваемых параметров и их типы на момент компиляции - так что однозначно утверждать о тольео одном проходе я-бы не стал.

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

sy-uname написал(а):

Вроде Java не самый из "неправильных" языков

А то! Java, английский и русский - вот мои языки. :-)

Не надо бередить мою рану... спор с администратором, который против развертывания Java в рамках новой версии ERP в конце года - вот и приходится мучаться пока с этим калекой ABAP-ом.

Речь просто не о том шла: разумеется, объявление переменной должно идти до ее использования (я просто решил пойти в шутке дальше: если у ABAP действительно глобальная видимость, то в принципе ничего не мешало бы ему и скушать приведенный вами пример - разницы-то 100% никакой!), мы же говорили о другом - о глобальной видимости в ABAP. В Java-то как раз есть понятие области видимости переменной... о чем и начинал говорить в первом сообщении. Самый наипростейший пример:

Цитата:

{
int i = 0;
}
i = 5; // compile error: i cannot be resolved

И все следствия из него, опять же пример, приведенный в первом сообщении на Java:

Цитата:

for (int k = 0; k < 5; k++) {
int i = 0;
System.out.println(++i);
}

выведет пять единиц в отличие от ABAP-а.

Правила форума

Область видимости переменных

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