LINUX.ORG.RU

нужен ли toplevl окну свой рабский интерпретатор?

 , ,


0

1

Доброго времени суток! Продолжаю ломать tkcon и возник очередной нубский вопрос.

В tkcon имеется главный интерпретатор и «рабские». Насколько я понимаю, это в основном сделано, чтобы пользователю была предоставлена виртуальная среда, которая отличается от основного интерпретатора тем, что в ней недоступна и не мешается под ногами инфраструктура самого tkcon. Чтобы можно было добавить в виртуальную среду какие-то новые возможности, ненужные в инфраструктуре (например, выполнение команд из истории по !!45). Ну и чтобы можно было ограничить возможности пользователя, если что.

Но возникает ещё и вопрос по стилю. Если у меня будет приложение с несколькими достаточно сложными toplevel окнами. У меня окно редактора, окно консоли, окно инспектора и т.п. Кроме того, я своё приложение собираю по кусочкам. Консоль у меня из tkcon, а редактор, скорее всего, будет какой-то сторонний. Следует ли в таком приложении завести по интерпретатору на каждое окно? Упростит ли это разработку или затруднит? Как вообще принято делать?

★★★★★

Последнее исправление: den73 (всего исправлений: 1)

Я обычно делаю по отдельному namespace на окно, в отдельном файле. В нем, процедура создания, допустим, Init, которая вызывается автоматически.

Или, как вариант, можно через TclOO отдельный класс замутить - если экземпляров окна может быть несколько.

anonymous
()
Ответ на: комментарий от anonymous

Ясно, спасибо. Наверное, буду выпиливать лишние интерпретаторы (когда-нибудь потом, когда допечёт).

den73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Хотя... А если несколько экземпляров окна? Таскать всё время окно как параметр? Тоже вариант, конечно.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Если несколько экземпляров, тогда традиционно делать окно с классом и объектами.

Или без ООП: сделать генератор уникальных ID и создавать оконные namespace в рантайме с уникальными именами. Может оно еще и проще окажется.

anonymous
()
Ответ на: комментарий от anonymous

А можно в коде увидеть пример неймспейсов? Потому что я не понял, это неймспейсы в смысле namespace eval или это в пространсте имён tk, типа _window8.mywidget.a и т.п.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

В смысле namespace eval, конечно. Например:

# генератор уникальных ID
namespace eval UID {
 variable uid
 
 proc getnew {} {
  variable uid
  incr uid
  return $uid
  }
  
 set uid 0
 }

set lns {}

# сделаем 3 топлевела
for {set i 0} {$i < 3} {incr i} {

    # toplevel обернутый в namespace
    namespace eval [UID::getnew]  {
     variable w
     
     proc Init {} {
      global lns
      variable w
      
      set w [toplevel .$UID::uid]
      lappend lns [namespace current]
      pack [button $w.bOK -text $UID::uid]
      }
     
     proc Delete {} {
      variable w
      
      destroy $w
      namespace delete [namespace current]
      }
     
     Init
     }
 }

update
after 1000

# удаляем по очереди
foreach ns $lns {
 [set ns]::Delete
 update
 after 1000
 }
 
exit

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

anonymous
()
Ответ на: комментарий от anonymous

Ааа. Я не знал, что внутри namespace можно процедуры ставить. Хотя тут выигрыш лишь в том, что вместо явного параметра w пишем variable w.

Здесь (и во многих других случаях генерации кода) возникает вопрос: а есть ли в тикле подобие компилятора? И не потеряем ли мы в скорости из-за того, что вместо имени неймспейса стоит выражение? Я читал, что там делаются какие-то оптимизации и внутри не всё строка. Есть чувство, что генерация неймспейса с вычисляемым именем может привести к каким-то потерям по оптимизации.

Но во всяком случае это решает мою задачу.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

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

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

anonymous
()

Если не нужен - продать на плантацию.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.