Дмитрий, между прочим, логика данных и архитектура имеют много общего. Представьте себе, что каждое свойство класса - это столбец в таблице БД с данными его экземпляров. Поле $role все еще кажется хорошей идеей? А JSON-поле для представления массива?
Антон Р., да не хулится ваше доброе! Продолжайте в том же духе, не обращая внимания на старперов, посмеивающихся над нубской нелепостью. И это пройдет ;)
Антон Р., я не про логику системы. Заборов-то вы можете понаставить. Речь про логику программиста, который с этим кодом работает. Для него пользователь - это данные. Не суперкласс, который в одно лицо умеет пол-админки, а данные.
Антон Р., в том плане, что если у вас Юзер умеет сам организовывать свою регистрацию, то вы можете сделать это в любом месте, где используете этот класс. Это правда то, что вам нужно?
Хотя бы представьте, что каждый раз, когда вы в IDE вызываете автодополнение по методам класса, вам первым делом лезет под руку этот самый метод регистрации. По-прежнему нужный только в одном-единственном месте сайта.
Антон Р., дополню одним практическим нюансом для лучшего понимания.
Вы же будете много где использовать этот самый класс Юзер. На хрена по всем этим дорогам таскать за ним регистрацию, которая нужна строго в одном месте сайта?
partisan42, "теперь" - это после перезагрузки или после изменения прав по этой инструкции?
В любом случае, это же Линукс. Загрузитесь в режиме восстановления или с внешнего носителя и разберитесь с правами на файлы.
WSGR, почитайте внимательнее описание этих уязвимостей - и последнее предложение в моем ответе.
Кстати, если вдруг найдете информацию об уязвимости, позволяющей кому бы то ни было при каких бы то ни было условиях вскрыть мой tc-контейнер с флешки, которая всегда у меня в кармане - буду очень благодарен за эту информацию. Пока что я не знаю ни одного способа сделать это, кроме ректального криптоанализа.
anikavoi, дело в том, что вы пытаетесь установить пакет, собранный не под ту систему, на которую вы его ставите. Отсюда и проблемы с зависимостями. Так что, если вам действительно без него никак - проще взять исходники и собрать, чем шаманить с зависимостями и, возможно, поломать их у других пакетов.
И если вы собираетесь всерьез заниматься администрированием - стоит понимать, что на каждом следующем сервере никаких фаров из коробки не будет...
pfg21, к примеру, если ты редактируешь из-под юзера "рутовый" файл, то ты хреновый администратор. Доверять программам, которые умеют и любят повышать привилегии, на Линуксе не стоит, имхо.
И вместо использования комбайнов, которые все умеют, но ты не знаешь, как - лучше бы разобраться с нативными инструментами. Для будущего.
Я бы предложил более оптимальный вариант - перерезать виндо-пуповину и не тащить ФАР в Линукс, осваивая нативные инструменты.
Запасной вариант, если невмочь - пересборка, да.
А что именно в этом процессоре такого революционного?
Вега 8 - не новость, более-менее свежее ядро ее знает из коробки.
Каких еще неожиданностей вы ожидаете?
Александр, вообще-то в приведенном вами тексте ничего не говорится о свойствах.
Ну, и наследование не бывает частичным. Дочерний класс в любом случае и в любом языке наследует родителя полностью. Приватные методы и свойства недоступны дочернему классу, но, естественно, существуют в нем, как часть унаследованного родителя.
Просто перестаньте пытаться исправить реальность под свое непонимание и разберитесь, что и как происходит. Можете почитать про наследование в С++ - там будут не общие фразы, а конкретный расклад данных в памяти. В пыхе и джаве этот механизм скрыт от программиста, но работает точно так же.
libAstral.dll обычно решает такие проблемы...