Роман Сохарев

Это почему сеттеры нарушают инкапсуляцию? Вовсе нет. Контроль сохраняется за внутренней логикой класса. И в отношении конструкторов, получается, странным образом интерпретируете инкапсуляцию. Логика ООП практически потеряет смысл, если нельзя будет настраивать поведение объектов. Каким образом с чем-либо взаимодействовать, если нет значений, которые можно передать объекту?

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

То есть, смысл инкапсуляции — это возможность реализации конкретной логики с распределением закрытости свойств. В одних случаях уместно закрыть доступ целиком, чтобы не нарушать базовое поведение объекта, когда разумно оставить установку значений только через конструктор, скажем, если цикл жизни объекта это некий конечный процесс, и может быть уместно запретить изменение этого поведения для дочерних классов, в других — допустимо менять свойства динамически, сеттерами, но оставляя обработку изменения за логикой класса.

Ошибка в регистре написания (буква L) - оказывается для unix это критично

В целом, понимайте схемы как пространства имен. Схемы помогают логически организовать структуру БД. Различные приложения или компоненты приложений внутри себя имеют более высокую связность, чем между собой, тоже самое и с данными в БД - часто таблицы сами по себе организуются в логические группы, причем внутри группы связей довольно много (внешние ключи, какие-то общие хранимые процедуры и т.д.), а между этими группами - мало или нет вовсе.

Важно понимать, что различные БД плохо подходят для логического группирования, т.к. разбиение по базам данных нужно скорее для администраторов, а не для приложений. Плюс, в большинстве СУБД, где существует понятие схемы, возможно ставить внешние ключи на таблицы в другой схеме, но нельзя на таблицы в другой БД. Иными словами, отдельные БД удобно создавать тогда, когда вы разделяете данные абсолютно не связанных приложений или сервисов. Например, складского учета и форума поддержки пользователей. С другой стороны, если вы хотите логически разделить таблицы в соответствии с компонентами одного приложения (например, корпоративный портал: 4 таблицы для поддержки авторизации, 10 таблиц для поддержки форума, еще 5 для чата со службой поддержки или отделом продаж) - то именно схемы будут удобным механизмом для этого.

Если сформулировать коротко, то разбиение на базы данных - это для администраторов БД, а разбиение на схемы - это для администраторов данных и разработчиков приложений, чтобы им же было легче.

А что будет если несколько юзеров будут на одну public-схему коннектиться?

Помимо того, что схема - это пространство имен, в большинстве СУБД это еще и пространство безопасности. Даже в рамках одного многокомпонентного приложения имеет смысл ставить границы безопасности для ограничения возможных потерь и разрушений в случае компрометации одного из компонент.

Вот допустим, у вас есть отдельная схема для таблицы авторизации и аутентификации и отдельная - для корпоративного форума. Сервис авторизации у вас выполнен отдельно от форума (например, авторизация выдаёт токены пользователю, с которыми он потом может зайти на форум). С точки зрения безопаности было бы логичным выдать сервису авторизации и форума различных пользователей в базе - тогда, при взломе форума невозможно будет получить доступ к паролям в базе или изменить права на портале, подправив данные в таблице ролей. Конечно, многие СУБД разрешают ставить права на отдельные таблицы, однако схема в данном случае играет роль контейнера и позволяет проставить единые правила для всех таблиц внутри неё.

то есть при работе в постгре предпочтительнее вместо отдельных баз делать разные схемы в одной

Как вы уже поняли - для независимых приложений, которые могут и должны существовать отдельно друг от друга - лучше делать разные базы. Тогда администраторы смогут спокойно переносить базы с сервера на сервер, независимо их бэкапить и т.д. Для компонентов одного приложения нужно использовать схемы.

Вот вам еще хороший пример. У вас есть приложение для ведения бухгалтерии и складского учёта на фирме. При этом сложилось так, что вам нужно хранить на одном сервере данные нескольких разных фирм (например, вы предоставляете готовый сервис под ключ нескольким клиентам). В этой ситуации более чем логично хранить данные разных клиентов в разных БД, а данные бухгалтерского и складского учета - в различных схемах в рамках одной БД конкретного клиента.

Открыть документацию и прочитать.
route('name', ['key' => 'value'])

Нужно дописать следующие:

resolve: {
    alias: {
        jquery:"/your/path/to/jquery"
    }

}

 plugins: [
        new webpack.ProvidePlugin({
            $: 'jquery',
        })
    ]

Итак, корректный ответ на поставленный вопрос:

Для начала, стоит понимать, что задача компилятора - взять сырец на X языке и перегнать его на Y язык. В современной жизни устоялась терминология "транслятора" и процесс "транслитерации", дабы не путать перегон в машинный код и на другой язык.

В классическом варианте этапы следующие:
1) Лексический анализ: Используя правила разбивает сырец на набор токенов (терминалов)
2) Синтаксический анализ: Используя правила и набор токенов структурирует их в AST
3) Семантический анализ: Проверяет корректность данных внутри AST (какого фига семантический анализ на этом этапе, а не позже, я, признаться хз).
4) Генерация промежуточного кода: В частности, трёхадресного и этот этап имеет смысл при реализации императивных языков. Трёхадресный код так же можно заменить на опкод, байткод или прочие "заменители" промежуточного кода.
5) Оптимизатор кода.
6) Результат (генерация в конечный код)
Во время всех процессов активно используется "таблица символов", грубо говоря "словарь".

Ориентируясь на эти данные я сделал несколько выводов и перестроил архитектуру следующим образом:
1) Парсинг (лексер + синтаксис)
2) Построение таблицы символов в немного фривольном формате: Имя + Тип + Адрес/Позиция в исходном документе + Метаданные (AST и проч.)
3) Билдер промежуточного кода (Reflection API)
4) Приведение типов
5) Валидация (вместо проверки корректности семантики из AST мне показалось удобнее оперировать высокоуровневым API, применяя некий паттерн матчинг, т.к. каждый тип проходит эту стадию сборки от 1 до 8).
6) Экстенды (есть спец.тип в GralphQL, который занимается манкипатчингом) -> после него переход к п.3
7) Рантайм (вызовы функций и проч) -> после него переход к п.3
8) Выходной результат (Reflection API)

Ключевым моментом становится метод а-ля рекурсивного спуска по этапам сборки от 1 до 8. Таким образом в самом рантайме (т.е. во время прохода по фазам их выполнению) можно дополнять данные в любую другую фазу. Пока хз как будет выглядеть на практике, но идея мне нравится.

Крайне рекомендую к прочтению:
1) Тут много инфы человеческим языком https://ps-group.github.io/compilers/ особенно вот эта статья понравилась: https://ps-group.github.io/compilers/fsm которая рассказывает о построении таблицы переходов в синтаксическом анализаторе.
2) И вот эта книжеца: https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D... Довольно сложная для понимания для неподготовленного читателя, но позволяет уточнить некоторые нюансы и ответить на вопросы.

Правильно понимаешь.

Как это делал я:

1) Сделал в базе поле пароля Nullable
2) Создал временное поле в БД password_md5
3) Во время авторизации авторизировал пользователя через связку username / password, если авторизация не прошла - username / password_md5.
4) Если связка username / password_md5 прошла, при этом поле password пустое - задавал полю password bcrypt значение введенного пароля

В течении нескольких месяцев база практически полностью наполнилась реальными паролями в bcrypt. Осталось несколько десятков неактивных юзеров, которым была выслана просьба поменять пароль, с отдельной страничкой, проверяющей старый пароль по полю password_md5 и задающей новый password.

Вот таким вот образом была мигрирована старая база. Извращение, но иначе - никак.
Удачи, надеюсь помог :)