some tips
	-- line-comment var = 5 -- получить тип у значения в ячейке var: var$ -- сравнить типы: var$ == $int

Здравствуйте, netch80
Наконец появилась минутка, чтобы ответить по вопросу namespace

| В си++ можно в разных местах открыть начало пространства имён, что-то в нём определить, а потом закрыть.
| И так несколько раз для того-же имени namespace -а можно повторно открывать в разных файлах.

В кси всё лежит в ячейках. У ячейки есть имя, и принадлежность.
К примеру ячейка модуля принадлежит модулю
Имя модуля начинается с собачки

| На примере ui либы это может выглядить так:

В модуле @main ячейка нэймспэйса с именем ui

-- file: ui-colors.ksi

@main

ui = #nest (
  colors
)

ui.colors = #nest (
  red   = 0h_ff_00_00
  white = 0h_ff_ff_ff
)

do = {
  &write_line( ui.colors.red )
}

Команда #nest формирует и возвращает новый тип, со статическими свойствами.
Это можно использовать как пространство имён.

Вы писали:

Если хочется чего-то выше уровня песочницы — понадобятся, иерархические.

Конечно они могут быть вложенными.

Вначале был указан список ячеек в нэсте ui
В этом списке пока только colors
Который тоже nest
Начальное значение для colors вынесено отделньно за скобку
Но могло быть и внутри, как у ячейки ui.colors.red

--

Добавим в nest ui ещё типы: coords, color
Через команду #add_nest

-- file: ui-types.ksi

@main

ui #add_nest (
  coords
  color
)

ui.coords = #struct ( x y )
ui.color = #struct ( r g b )

-- usage:

test_types = {
  pos = ui.coords(2, 2)
  clr = ui.color(200, 200, 200)
}

В том-же файле, или в отдельном — не так важно.

--

Через #add_nest можно статики добавлять и к структуре тоже

-- file: ui-color-actions.ksi

@main

ui.color #add_nest (
  from_code
)

ui.color.from_code = #fn ($int: code)
{
  #ret = ui.color(/* битовые вычисления */)
}

-- usage:

test_color = {
  clr = ui.color.from_code( ui.colors.white )

  clr_code = (
    clr !to_code
  )

  ( clr_code <> ui.colors.white ) #then { /* log: test_failed */ }
}

Метод to_code для типа ui.color в этом примере не определён.
Синтаксис для добавления методов — в отдельном reply запланирован)

	вы спрашивали
	Я не понял, к чему '!' впереди "!as". Через восклицательный знак — это вызов метода cell !method cell !method(params) Через точку — доступ к свойству cell.property Через стрелочку — доступ к атрибуту cell->attr так имена у метода, свойства и атрибута могут совпадать, и не возникнет ambiguity

--

Попытка через круглые скобки создать экземпляр из типа, который сформирован командой #nest, вернёт тот-же тип.

do {
  -- attempt to make nest instance:
  var = ui.colors()

  -- type of nest instance:
  type = var$

  -- ... and nest itself
  ( type == ui.colors ) #then { &write("same") }
  -- is the same thing

  -- but type of nest:
  ui.colors$ == $type -- ui.colors is type
  -- is $type
}

Тут var$ — это способ узнать тип

--

На случай если разработчик кси библиотеки захочет запретить добавлять в свой nest дополнительные статик свойства через #add_nest,
то можно ввести команду #nest_once (или как её лучше назвать?)

@some_lib

my_nest = #nest_once ( a b c )

my_nest #add_nest () -- ошибка!

Но может быть вы предложите вообще запретить через #add_nest добавлять статики именно в #nest ?
Чтобы весь перечень статик ячеек был всегда в одном месте ... И не пришлось бы их искать по разным файлам

Как считаете, добавлять статики в структуру, в перечисление, и даже в функцию — хорошая идея?
* всё той-же командой #add_nest

	some tips
	-- line-comment var = 5 -- получить тип у значения в ячейке var: var$ -- сравнить типы: var$ == $int

Здравствуйте, netch80
Наконец появилась "минутка", чтобы ответить по вопросу namespace

| В си++ можно в разных местах открыть начало пространства имён, что-то в нём определить, а потом закрыть.
| И так несколько раз для того-же имени namespace -а можно повторно открывать в разных файлах.

В кси всё лежит в ячейках. У ячейки есть имя, и принадлежность.
К примеру ячейка модуля принадлежит модулю
Имя модуля начинается с собачки

| На примере ui либы это может выглядить так:

В модуле @main ячейка нэймспэйса с именем ui

-- file: ui-colors.ksi

@main

ui = #nest (
  colors
)

ui.colors = #nest (
  red   = 0h_ff_00_00
  white = 0h_ff_ff_ff
)

do = {
  &write_line( ui.colors.red )
}

Команда #nest формирует и возвращает новый тип, со статическими свойствами.
Это можно использовать как пространство имён.

Вы писали:

Если хочется чего-то выше уровня песочницы — понадобятся, иерархические.

Конечно они могут быть вложенными.

Вначале был указан список ячеек в нэсте ui
В этом списке пока только colors
Который тоже nest
Начальное значение для colors вынесено отделньно за скобку
Но могло быть и внутри, как у ячейки ui.colors.red

--

Добавим в nest ui ещё типы: coords, color
Через команду #add_nest

-- file: ui-types.ksi

@main

ui #add_nest (
  coords
  color
)

ui.coords = #struct ( x y )
ui.color = #struct ( r g b )

-- usage:

test_types = {
  pos = ui.coords(2, 2)
  clr = ui.color(200, 200, 200)
}

В том-же файле, или в отдельном — не так важно.

--

Через #add_nest можно статики добавлять и к структуре тоже

-- file: ui-color-actions.ksi

@main

ui.color #add_nest (
  from_code
)

ui.color.from_code = #fn ($int: code)
{
  #ret = ui.color(/* битовые вычисления */)
}

-- usage:

test_color = {
  clr = ui.color.from_code( ui.colors.white )

  clr_code = (
    clr !to_code
  )

  ( clr_code <> ui.colors.white ) #then { /* log: test_failed */ }
}

Метод to_code для типа ui.color в этом примере не определён.
Синтаксис для добавления методов — в отдельном reply запланирован)

	вы спрашивали
	Я не понял, к чему '!' впереди "!as". Через восклицательный знак — это вызов метода cell !method cell !method(params) Через точку — доступ к свойству cell.property Через стрелочку — доступ к атрибуту cell->attr так имена у метода, свойства и атрибута могут совпадать, и не возникнет ambiguity

--

Попытка через круглые скобки создать экземпляр из типа, который сформирован командой #nest, вернёт тот-же тип.

do {
  -- attempt to make nest instance:
  var = ui.colors()

  -- type of nest instance:
  type = var$

  -- ... and nest itself
  ( type == ui.colors ) #then { &write("same") }
  -- is the same thing

  -- but type of nest:
  ui.colors$ == $type -- ui.colors is type
  -- is $type
}

Тут var$ — это способ узнать тип

--

На случай если разработчик кси библиотеки захочет запретить добавлять в свой nest дополнительные статик свойства через #add_nest,
то можно ввести команду #nest_once (или как её лучше назвать?)

@some_lib

my_nest = #nest_once ( a b c )

my_nest #add_nest () -- ошибка!

Но может быть вы предложите вообще запретить через #add_nest добавлять статики именно в #nest ?
Чтобы весь перечень статик ячеек был всегда в одном месте ... И не пришлось бы их искать по разным файлам

Как считаете, добавлять статики в структуру, в перечисление, и даже в функцию — хорошая идея?
* всё той-же командой #add_nest