Это очевидное поведение, которое не нарушает ничего вообще, по-этому ошибок и нет. И что-то поломать с таким поведением нельзя. Класс А ничего не знает о В, он работает как задумывался обращаясь к приватной переменной. Класс В ничего не знает о приватном свойстве, у него не может быть таких обращений, по-этому если он обращается к property - значит это свойство нужно искать в В классе
Ведь на практике, с этим можно делать так, чтобы одно и то же свойство имело разные модификаторы доступа в разных подклассах.
Не совсем. Свойства property в классе В просто нет. По-этому о "разных модификаторах одного свойства" речи и не идет. У нас совсем другое свойство просто с тем же именем. А вот если в А будет публичное, а в В захотите приватное - будет ошибка. Ибо можно поиметь проблем. И, опять же, если в А было протектед, а в Б - публичное, то проблем не будет. Хотя этот код и будет плохо пахнуть.
Через метод будет возвращаться A, а через прямой доступ $b->property - B. Магия)
Ну это странный аргумент. Вас же не удивляет, что $b->prop дает 1, а метод с кодом return $this->prop + 1; выдаст 2? Я вижу прямую аналогию ;) Свойство - это свойство, метод - это метод. Но в общем стараться не делать свойства в наследниках с теми же именами, что и приватные в базовом - даже плюс к запаху кода будет ;)
Вообще имеет. Для лицензионного договора - нет. Другое дело, что если "перетерли" было в почте, это уже письменные доказательства. А если в почте было упоминание о признании почтового адреса простой электронной подписью - то это уже полноценный письменный договор. Хотя вообще все еще проще - пересланные условия использования - это оферта, а оплата - ее акцепт. Т.е. обсудив в почте условия лицензии покупатель, перечислив деньги, совершил акцепт этих условий.
Выделение - это часть совпавшего регулярного выражения (которое в скобочках), которое можно получить отдельно потом. Как по порядковому номеру ($1 $2 ...), так и по имени, если оно задано. Т.е. (regexp) - это простое выделение, а (?<varname>regexp) - именованное выделение с именем varname.
Можно, конечно, если очень хочется - cygwin есть 100500 лет. Другое дело, что оно почти никому не нужно в винде, учитывая, что разработка ведентся внутри виртуалки, внутри нее же можно и wget сказать.
Немного непонятно, что вы хотите. Для каждого разного токена отдельный кеш? Одинаковая страница для всех токенов? Если токена нет - кешировать или нет?
Не, все-равно не понял, что хотите. Распишите - какой урл вбивается на com сервер, и какой урл должен быть запрошен с ru сервера в итоге. И какие урлы, вбитые в com сервер не должны попадать на ru сервер.
Почему example.ru? У вас, следуя из вопроса, по example.com/19.txt должен выдаваться документ, лежащий в example.ru/home/pages/19.txt. Если не так - пишите вопрос иначе.
Можно обойтись без отдельной колонки создав expression index. Такой вариант проще, сам обновляется, занимает меньше места на диске, но при запросах на поиск нужно указывать полностью выражение создания tsvector, чтобы этот индекс был найден. Тут вот расписано достаточно понятно https://www.postgresql.org/docs/9.5/static/textsea...
Меня вот тоже смутило отутствие упоминания индексов про postgresql, по-этому гадать не стал. Вес можно задавать при запросе, это я что-то ступил. Сейчас дам пример в ответе.
У вас один FTS индекс на два поля или отдельные FTS индексы на каждое поле? Вес нужен постоянно (можно задать при создании индекса) или в разных запросах разный вес?
Sanes: Я так понял, у него там sh скрипт в цикле крутится. До или после - это уже нюансы реализации, о которых невозможно говорить без конкретной расписанной задачи.
После скачивания, ну и до скачивания тоже. Скачали файл, проверили рамер папки... если превышение - вышли. Можем даже последний файл удалить. Я не знаю какая логика для вас допустима. Многопоточность тут будет сильно мешать и усложнит логику. Можно, например, перед скачиванием запрашивать размер файла и резервировать под него место, что бы другие потоки зря не качали.