Категорически не согласен...

Sumo 14.12.2006 08:19

... тут обратная совместимость просто необходима - это очень кардинальное изменение, которое может привести к крайне трудноотлавливаемым ошибкам при работе со "старым" кодом, а пользы нет никакой. Вобще говоря, при нормальном проектировании, количество локальных переменных в методах большим быть не должно - с трудом верится, что код из 5-15 строчек может требовать "декларации локальных переменных по 300 символов" - тут явно повод для "рефакторинга".

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

А вот идея с возможностью описания локальных переменных не только в заголовке метода, но и непосредственно в коде очень даже удачная (в варианте "$local.variable[]"), а если еще можно сделать, чтобы область действия такой переменной была ограничена не всем методом, а блоком "{ }", то будет нам полное счастье.

Есть единственное изменение, которое действительно нужно сделать и его обратно несовместимостью можно пренебречь: методы класса, имена которых совпадают с именами операторов, должны иметь более высокий приоритет, чем операторы. Чтобы было понятно приведу пример:

auto.p
@method[aValue]
  $result[$aValue]

class.p
@CLASS
class.p

@create[]
  $_test[test]

# здесь мы хотели, чтобы вызвался метода класса, 
# а вызовется "глобальный" метод
  $_len[^method[test]]

# никто не мешает сделать так, чтобы вызывался метод
# класса, а если нужен оператор, то позвать его можно так:
  $_res[^MAIN:method[test]]

@method[aValue]
  $result(^aValue.length[])

Писать постоянно ^self.method или не иметь возможности ввести в класс переменную $cache достаточно неудобно.

---