Вопрос наусщный - как обратиться к полям класса из субкласса. (Не выверты, бесплатно, без СМС :).

andylars 25.12.2014 10:35 / 25.12.2014 10:47

Сабж.
Вопрос отдельный и насущный,
не имеет отношение к моим мытарствам-экспериментам.

Суть вопроса каменте внутри кода в @fLogin[]

@main[]

$Session[^SiteModel::create[]]

^Session.Auth.fLogin[by_sid]

^Session.Navigator.fRender[
   $.interface[HTTP]
   $.template_name[Main]
   $.template_degradation[auto] 
   $.router[Main]
]

#---

@CLASS
SiteModel

@create[]

$Data[
  $.UserStatus[]
  $.OtherCommonVars[]
]

$Auth[^Auth::create[$cookie:sid]]
$Billing[^Billing::create[]]
$Navigator[^Navigator::create[]]
...

@CLASS
Auth

@create[]

@fLogin[lc_param]
#...
# Вопрос: как мне отсюда записать в SiteModel.Data[ $.UserStatus[signed] ]
#         в контексте экземпляра SiteModel.self разумеется
#

@fLogout[]
#...

@fRegister[]
#...

Ясно-понятно, что я могу обойтись без суб-классов, и положить всё
плоско и процедурно в SiteModel в виде портянки методов, типа

@Auth_login
@Auth_logout

и так далее...

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

Пример применения обширный, навскиду функция: посмотреть как смотрится блок записей глазами public-пользователя, тут может понадобиться создать Auth-экземпляр с public-статусом, то и случаи когда мне в рамках сессии пользователя нужна параллельная работа с другими частями сайта но под другим пользователем/режимом...

P.S.:
Опять же так можно и вовсе всё сделать плоскими методами в MAIN, нафиг они тогда вообще сдались эти классы )) (В рамках эксперимента давно на них гляжу с неодобрением, с каждым разом утверждаясь в мыслях, что класс-ориентированная парадигма в своем классическом исполнении - какая-то абстрактная помойка и толька кажется гармоничной, все больше поглядывая на вложенные структуры и функторы OCaml)
Ради чего они? Ради контекста переменных/полей и статуса(инициировано)?
Это легко заменяется вложением всех полей в разные ключи хеша оставаясь технически в процедурном стиле.
В остальном только ради красивого нейминга. В то время, как работа с иерархией (композиционной способностью классов - никакая).
Ну и наследование, это не более чем шаблон, а точнее прототип из прототип-ориентированной парадигмы, которого просто не хватало в класс-ориентированной.

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

---