Когда мы начали в университете изучать нейронные сети, меня заинтересовал один вопрос. Биологические нейроны — они же не знают математики. Они не умеют вычислять производные сложных нелинейных функций, умножать матрицы, а обучение с учителем это сам по себе биологически неправдоподобный метод. Значит принцип работы у них немного другой. Почему в таком случае уделяется большое внимание большим сложным алгоритмам? Да, они дают какие-то результаты, но дальше распознавания пятен на шкуре леопарда почти ничего не продвинулось.
Мне кажется, лучше было бы изучать возможные принципы функционирования отдельных клеток и их взаимодействия. А то получается, что у нас «сеть сама распознаёт», а как именно это происходит, никто не знает.
У меня то же самое — сложно сделать задачу, которую раньше не решал или с которой не сталкиваешься постоянно, если разговариваешь с кем-то или просто кто-то смотрит и ждет. Я не сталкиваюсь, например, с алгоритмическими задачами, но при этом многие из них могу решить, если подумать над ними некоторое время в спокойной обстановке и представить все в деталях.
Я думал над этим, почему так происходит. Возможно, это из-за того, что работают разные отделы мозга. У кого-то общение забирает фокус внимания (как на этой картинке), и серьезно думать не получается, у кого-то получается совмещать и переключаться, кто-то такие задачи часто решает, и ему не надо задумываться, кто-то может вообще мыслит по-другому и у него это взаимосвязано.
То есть, это не боязнь завалить собеседование, или боязнь собеседника, а нестандартная для мозга ситуация, которая требует внимания и ресурсов, которые забирает на себя общение с собеседником. Примерно как в квантовой физике — наблюдение влияет на результат наблюдения.
Не пишите что поменялось — это всегда видно по диффам
Думаю, писать что поменялось тоже нужно. Это полезно, когда надо найти конкретный коммит из разряда «точно помню, что-то где-то я такое делал», или точную дату изменений. Смотреть дифф каждого коммита утомительно. А подробный ответ на вопрос зачем обычно есть в таск-трекере. Я обычно пишу как в последнем пункте — «что и зачем я сделал» в сжатом виде. А так со всем согласен, правильно написано.
Это не узкоспециализированное направление. Вы описали массив в PHP. Ваш DataObject практически ничем от него не отличается.
Что имеем в результате? Контейнер для переноса любых данных.
Массив в PHP это и есть контейнер для переноса любых данных, мы его имели и до результата.
Можно все то же самое делать через аннотацию @property
Почему бы просто не объявить нормальный класс с нормальными свойствами, унаследованный от ArrayObject? Потому что вам удобнее по-другому? Хороший аргумент, что сказать.
Скрытый текст
class GetForDependentCalc extends DataObject
{
public $baseCalcData;
public $dependentCalcData;
}
$a = new GetForDependentCalc();
$a->test = 'test';
var_dump($a);
/*
object(GetForDependentCalc)[1]
public 'baseCalcData' => null
public 'dependentCalcData' => null
public 'test' => string 'test' (length=4)
*/
class DataObject extends ArrayObject
{
public function __construct($input = [], $flags = ArrayObject::STD_PROP_LIST, $iterator_class = 'ArrayIterator')
{
parent::__construct($input, $flags, $iterator_class);
}
}
Более того, можно «научить» универсальный контейнер автоматически преобразовывать хранимые в нем данные в формат, например, JSON
То есть, вы предлагает в каждый контейнер, который надо сериализовать в JSON, копировать одну и ту же функцию сериализации, вместо того чтобы держать ее отдельно и передавать объект как параметр?
можно получить весьма интересные последствия в виде цепочек функций-процессоров, где выходные данные одних функций являются входными данными для других
Выходные данные одних функций всегда можно передать в другие функции. На то они и данные. Другое дело, что функция может ожидать на вход данные определенного формата, и произвольный DataObject ей не нужен.
Вы так красиво вынесли за скобки почти все, что можно было указать в пункте «другое») Вопрос кадрового обеспечения вузов, по-моему, вообще один из главных, особенно в регионах. Какой смысл преподавателю что-то внедрять, если он сам «не шарит».
Я за участие в проектах. Только не в «мегапроектах», так, как вы их описали (хотя может я не так понял). Ну написали студенты всем курсом программу антиплагиата, на следующий год предыдущий курс ее дорабатывал, а последующим выпускникам только мелкие баги исправлять.
Можно сделать примерно следующее. Есть некоторый исходный код, это рабочий проект в каком-то состоянии, необязательно крупный. Есть набор задач по его изменению. То есть стандартная ситуация почти для всех реальных проектов. Студенты все вместе в течение курса выполняют эти задачи, участвуют в разработке проекта. Тут и система контроля версий, и работа с чужим кодом, и тестирование, и работа с конкретным стеком технологий. Обучение одного курса заканчивается, студенты следующего курса получают тот же самый проект в исходном состоянии, и производят разработку по тем же задачам. Списать у предыдущего курса будет проблематично, потому что все пишут по-разному, и все равно надо понимать, как работает этот код.
Такие проекты можно придумать практически для любого набора языков и технологий — низкоуровневая разработка, десктоп + БД, веб-разработка. Или можно обратиться в IT-компании, чтобы подготовили что-нибудь подобное на основе своих старых проектов и задач по ним, то что разгласить не жалко. Лучше, конечно, если это будет введено более глобально, на уровне программы обучения, чтобы и до регионов дошло.
> Все ваши аргументы на уровне — но ведь принято думать иначе
Я вроде бы обосновал свою точку зрения. Если у вас есть возражения относительно аргументов, прошу их озвучить. Мои аргументы на уровне — в реальности немного не так, как вы описываете.
> Но вижу и проблемы
Обозначьте, пожалуйста, эти проблемы. Я вас спрашивал об этом в личке, но вы ушли от ответа и сказали: «К сожалению никаких сохраненных ссылок не осталось, но помню, что по поиску в сети сразу выпадает несколько статей и дискуссий. Можно для затравки посмотреть обсуждение здесь».
> Но поскольку для нас (в жизни) при различении концепта атрибуты отступают на второй план (мы видим функциональный образ стола, а не считаем его ножки).
Попробую предпринять последнюю попытку. Для вас в жизни при различении концепта стула и стола атрибуты имеют первичное значение. Независимо от того. что вы про эти атрибуты думаете. И у стула, и у стола есть 4 ножки и плоская поверхность. Предназначение плоской поверхности — это один из атрибутов. Можно сесть на маленький пенек и съесть пирожок, опираясь локтем на большой пенек, и поставив на него кружку с водой. В данном случае, маленький пенек это стул, большой пенек это стол, вне зависимости от количества ножек. То есть, функциональное предназначение — один из признаков.
А еще пенек — это оставшаяся часть дерева после спиливания. Этому признаку соответствуют оба пенька. То есть, мы не можем отнести объект к одной конкретной иерархии, у нас есть выбор, который делается на основе признаков ситуации и признаков сущности. И концепты — это всегда понятия, определяющие набор признаков. Иначе «концепты, относимые, к социальной, этической, эстетической областям» не могли бы быть представлены в виде реакции биологических клеток мозга приматов, которые (клетки) понятия не имеют обо всяких абстракциях.
Я говорю о том, что ваши концепты и есть атрибутивное описание. Как вы отличаете книгу от автомобиля? Только на основе атрибутов.
> Остановимся на последней мысли подробнее. Например, некий индивид (нечто у меня в гараже) является автомобилем (фиксируется как подпадающий под концепт «автомобиль») не потому, что он соответствует некоторому перечню атрибутов (модели) концепта, а только потому, что я так решил, игнорируя то, что у этого индивида есть только одно колесо
Он соответствует вашему представлению об автомобиле. А для соседских детей автомобилем может быть кузов без руля и сидений, стоящий во дворе.
> индивид мул рождается мулом, существует как мул и умирает мулом, поэтому подпадает под концепт «мул»
Некоторое живое существо рождается как %entity%, существует как %entity% и умирает как %entity%. Вот эта %entity% подпадает под концепт «мул», «собака», или «комар»?
Извиняюсь за количество текста, просто есть вопросы по многим моментам.
> Описание предметной области начинается с выделения объектов, и мы вынуждены это делать еще не имея никакой классификации, которую мы могли бы использовать в качестве шаблона для их различения.
Оу. Как же мы в обычной жизни-то различаем объекты, у нас же нет никакой классификации, которую можно использовать…
> нам не требуется проводить анализ, фиксировать атрибуты
Это еще почему? Вы не сможете отличить соседскую кошку, которую вы никогда раньше не видели, от соседской собаки, которую вы никогда раньше не видели? Думаю, что сможете, и сделаете это на основе ранее известных вам атрибутов, или признаков.
> с которыми и происходит сопоставление выделенного из среды индивида
Простите, а как оно происходит? Не на основе ли атрибутивного описания?
> Жучка пожизненно собака
Жучка пожизненно это живое существо с некоторым набором характеристик. Мы относим ее к собакам, потому что у нее есть некоторые известные нам признаки собаки. Кстати, мул это осел или кобыла?
> если бы эта (например) кошка не была бы кошкой, продолжала бы она существовать? Ответ отрицательный
Тут все верно. Кошка не была бы кошкой, потому что у нее была бы другая генетика. Кстати, возвращаясь к предыдущему примеру, если бы мул не был бы мулом, продолжил бы он существовать? А если бы он не был потомком мула?
> А если бы мы спросили, существовала бы студентка, не будь она студенткой? Ответ отрицательный
А тут неверно. Существовала бы школьница Маша, или секретарша Маша, но студентка Маша тоже бы не существовала, аналогично кошке. Потому что в этом случае Маша не подходит под описание того, что мы подразумеваем под понятием «студентка».
> А вот для разъяснении значения понятия «ездовая» потребуется указать на нарты и объяснить понятие «езда в упряжке», и лишь потом заключить, что Жучка «ездовая» потому, что она имеет отношение к «нартам» и «езде»
А для разъяснения понятия «лайка» нам надо указать на лайку и объяснить, какие именно параметры мы считаем принадлежностью лаек, и лишь потом заключить, что Жучка — лайка. Пример — две лайки разного окраса, и два щенка лайки и таксы одного окраса.
> Или, к примеру, человек подпадает под понятие «студент» не просто сам по себе, а только по причине наличия связи «персона – ВУЗ». Но мужчиной этот человек является имманентно – независимо от каких-либо отношений с другими объектами.
Ничего подобного. Студента мы определяем по одним признакам, мужчину по другим. Пример — некоторые лягушки могут менять пол. Другой пример — дожевые черви гермафродиты. Кто такие самка, самец, гермафродит? Как бы вы описали эти понятия?
> Вряд ли найдется такой аналитик, который сможет объяснить, что такое «ездовая собака» без ссылки на понятие «езда»
Понятие «ездовая собака» это само по себе связь между понятиями. Которое, кстати, обозначает некоторую характеристику — для чего может использоваться эта порода собак. Связь между сущностями вполне может быть самостоятельной сущностью. Даже само слово «связь» — существительное.
> Жучка подпадает под них просто по факту своего рождения: является животным, собакой и лайкой. И для того, чтобы это утверждать, не требуется обращаться к каким-либо другим понятиям, пояснять, что, кроме животных, есть еще и растения, что есть еще кошки и овчарки.
Ничего подобного. Если бы не было овчарок, никто бы не стал выделять понятие лайки, называли бы просто «собака».
индивида Жучку мы называем лайкой, если она входит в множество лаек, а само множество лаек определяем как совокупность всех индивидов лаек
Я не специалист в теориях, возможно где-то и рассматривается принадлежность ко множеству как единственный вариант связи. Но в обычном бытовом смысле мы Жучку называем лайкой, если она соответствует общепринятым признакам лайки. У вас это называется «подпадание индивида под понятие». Только не очень понятно, зачем вы посвятили этому 3 абзаца. Выглядит так, как будто вы придумали проблему с неправильным определением понятий и потом доказали, что неправильные определения это неправильно.
связь индивида «Жучка» с понятием «ездовая» существенно отличается от связи с понятием «лайка»…
К примеру, Жучка могла быть признана абсолютным чемпионом породы, а потом утерять это звание, что принципиально невозможно с концептуальными понятиями
Неа. Здесь тоже идет соответствие признакам. К примеру, абсолютным чемпионом можно назвать победителя последней мировой выставки. Одна собака может несколько раз побеждать в выставках и соответствовать этим признакам, потом победит другая, и этим признакам будет соответствовать уже она.
Аналогично Жучка может перестать соответствовать признакам лайки, если набор признаков лайки поменяется, например, в результате какой-нибудь всемирной конференции биологов. Другой пример, можно считать банан деревом, а потом окажется, что это трава.
Жучка не может быть и собакой, и кошкой
Потому что в наборах признаков собаки и кошки есть взаимоисключающие признаки, в данном случае связанные с генетикой.
Жучка является частью псарни и частью упряжки
Тут, конечно, есть отношение «часть-целое», но если рассмотреть это с другой стороны, то все снова сводится к набору признаков. У нас есть некоторое представление о том, что такое упряжка собак, и один из признаков — это некоторое множество собак. На привале собак можно распрячь и отпустить, тогда можно будет сказать, что у нас пустая упряжка.
То есть, все 3 случая — это соответствие определенному набору признаков. Может в теории традиционным является выделение множеств, но на практике выделение признаков давно уже применяется в программировании и проектировании предметной области приложения. Правда, там есть свои технические сложности касательно задания и определения соответствия, но это уже другой вопрос.
Я не сказал, что текст сложный, я сказал, что он дает неправильную информацию при объяснении особенностей. Конкретно:
— Про бэкенд. Из текста и из вашего комментария складывается впечатление, что бэкенд вторичен. На самом деле он «главнее», потому что в нем находится логика. Если на фронтенде нет проверок, а на бэкенде есть, проблем с данными не будет. А если на бэкенде нет проверок, а на фронтенде есть, то можно отправить неправильные данные вручную, без фронтенда. У вас в статье примерно то же самое, но акцент сделан не на том.
— Про intval. Тут вы поправили, но intval тут роли не играет. «echo 0123» тоже выведет 83. Это документированное обозначение 8-ричных чисел, так же как 0x123 обозначение для 16-ричных. Такое же обозначение используется, например, и в C++, и в Java, и в JavaScript. Из текста же складывается впечатление, что это какая-то фишка PHP, сходная с багом.
— Числа с плавающей точкой — проблема PHP. «Я говорил конкретно про PHP — в нём эта проблема есть». Это что-то вроде «у меня ваша программа не работает — так электричества же нет, поэтому компьютер не включается — ну и что, я же в вашей программе работаю».
— В проблеме с разрядностью про разрядность ничего не сказано. Не сказано, что в большинстве случаев такая разрядность не нужна, особенно в проектах начинающих. Если бы я не знал причину, у меня бы сложилось впечатление, что это опять какой-то косяк PHP.
HTML является разновидностью текста
А текст является разновидностью байтов. Это не значит, что надо с любыми данными работать как с байтовым массивом. У вас как-то все сумбурно — как будто разметка это разновидность перевода строк.
Ну, естественно! Если вы не сталкивались — значит проблема не существует
Там написано, что я с этой проблемой не сталкивался, я не сказал, что ее не существует. Вообще это был своего рода намек «Уважаемый автор, не расскажете ли вы, с какими именно задачами вы столкнулись, что там переводы строк это серьезная проблема. Я вот не сталкивался, вдруг понадобится, хоть буду знать». У вас половина статьи о том, что это важно, но нет никаких примеров, которые бы эту проблему иллюстрировали. Пара неправильно отформатированных строк это не примеры, потому что непонятно, как они появились.
поэтому бэкэнд (та часть, которая производит фактическую обработку данных на стороне сервера и записывает изменения в БД) ОБЯЗАН всегда повторять расчёты фронтенда
Наоборот, фронтенд обязан повторять расчеты бэкенда. Вернее даже не так. Фронтенд может повторять проверки бэкенда — для ускорения работы и улучшения UI, а может и не повторять. На бэкенде все проверки всегда должны быть в полном объеме.
Тут сразу начинаются пляски с бубном по поводу символа перевода строки.
Насколько я знаю, браузеры вполне неплохо сами разбираются с разными переводами строк. В любом случае, это исправляется простой заменой разных переводов строк на нужные в функции получения данных из файла.
И тут появляется великий HTML
Не надо путать текст и HTML. Если в файле есть <br>, значит это разметка, и не надо работать с ней как с текстом. Если разметка расположена вперемешку с текстовыми файлами, значит это проблема в архитектуре конкретного проекта. Исправить можно аналогично, через замену по регулярному выражению. Переводы строк тут ни при чем.
Кому приятно вместо отформатированного по параграфам текста увидеть что-то вроде
Это ошибка только в форматировании вывода. Любая замена переводов строк эту проблему не решит.
Какое число получится в переменной, если в PHP-бэкэнде написать intval('0123')
Выведет 123. Кстати, вам надо было поставить там ссылку на документацию по intval() (заодно и сами бы почитали).
Если записать без кавычек, то будет 83, но это уже изначально int, записанный в 8-ричной системе. Это аналогично записи 0x123 без кавычек для 16-ричной. Лидирующие нули в строках на результат не влияют. А для преобразования string в int лучше использовать приведение типов "(int)$var".
Отдельная песня — числа с плавающей точкой в PHP и их сравнение
PHP здесь ни при чем, так происходит во всех языках, это особенность представления таких чисел в процессоре.
Ну, это те самые веселые числа, объявленные как BIGINT(20,0) в БД
Откуда у INT дробная часть?
ALTER TABLE `test_table` ADD COLUMN `test_column` BIGINT(20,0) NOT NULL;
/* SQL Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '0) NOT NULL' at line 1 */
«Что бы полностью понять суть проблемы», надо знать, что такое разрядность. Да и вообще, для большинства таблиц простого INT хватает. Не собираетесь же вы в каждой таблице по 3 миллиарда записей хранить?
многострочные строки (даже нормированные) требуют разного отношения при выводе в HTML, JS или при сохранении в БД
Не знаю, что за задачи этого требуют, лично я ни разу не сталкивался. Обычно что сохраняем, то и выводим, плюс экранирование. Для javascript можно выводить через json_encode().
Мне кажется, считать адрес объектом-значением можно, если он нужен только для информации и выводится один раз где-нибудь в профиле пользователя, а реальность адреса не имеет значения. Но фактически это самостоятельная сущность, никак не связанная с пользователем, и она может изменяться. Например, переименование улицы. Местоположение на карте осталось то же самое, этажность и номер дома те же, люди и организации из этого дома никуда не переехали, а текстовое представление адреса изменилось. Это аналогично изменению фамилии у человека.
С адресом плохой пример. Дом снесли — адрес исчез, ну или «стал неактивен». А например цифру 2 отменить нельзя. Кроме того, у человека или организации может быть несколько адресов.
Простите, а причем здесь программирование? Вы предлагаете ввести изучение 3D, при этом на вопрос «зачем?» начинаете уходить от ответа и тыкать пальцем в другие предметы. Я вот считаю, что в школе и без того слишком много информации, которую нужно изучить, особенно в старших классах. И для введения дополнительных предметов нужны очень веские причины. А у вас в разделе «Зачем» только домыслы в стиле «я так хочу». Так что присоединяюсь к вопросу — зачем это надо, что это дает?
Мне кажется, лучше было бы изучать возможные принципы функционирования отдельных клеток и их взаимодействия. А то получается, что у нас «сеть сама распознаёт», а как именно это происходит, никто не знает.
Я думал над этим, почему так происходит. Возможно, это из-за того, что работают разные отделы мозга. У кого-то общение забирает фокус внимания (как на этой картинке), и серьезно думать не получается, у кого-то получается совмещать и переключаться, кто-то такие задачи часто решает, и ему не надо задумываться, кто-то может вообще мыслит по-другому и у него это взаимосвязано.
То есть, это не боязнь завалить собеседование, или боязнь собеседника, а нестандартная для мозга ситуация, которая требует внимания и ресурсов, которые забирает на себя общение с собеседником. Примерно как в квантовой физике — наблюдение влияет на результат наблюдения.
Думаю, писать что поменялось тоже нужно. Это полезно, когда надо найти конкретный коммит из разряда «точно помню, что-то где-то я такое делал», или точную дату изменений. Смотреть дифф каждого коммита утомительно. А подробный ответ на вопрос зачем обычно есть в таск-трекере. Я обычно пишу как в последнем пункте — «что и зачем я сделал» в сжатом виде. А так со всем согласен, правильно написано.
Массив в PHP это и есть контейнер для переноса любых данных, мы его имели и до результата.
Почему бы просто не объявить нормальный класс с нормальными свойствами, унаследованный от ArrayObject? Потому что вам удобнее по-другому? Хороший аргумент, что сказать.
То есть, вы предлагает в каждый контейнер, который надо сериализовать в JSON, копировать одну и ту же функцию сериализации, вместо того чтобы держать ее отдельно и передавать объект как параметр?
Выходные данные одних функций всегда можно передать в другие функции. На то они и данные. Другое дело, что функция может ожидать на вход данные определенного формата, и произвольный DataObject ей не нужен.
Я за участие в проектах. Только не в «мегапроектах», так, как вы их описали (хотя может я не так понял). Ну написали студенты всем курсом программу антиплагиата, на следующий год предыдущий курс ее дорабатывал, а последующим выпускникам только мелкие баги исправлять.
Можно сделать примерно следующее. Есть некоторый исходный код, это рабочий проект в каком-то состоянии, необязательно крупный. Есть набор задач по его изменению. То есть стандартная ситуация почти для всех реальных проектов. Студенты все вместе в течение курса выполняют эти задачи, участвуют в разработке проекта. Тут и система контроля версий, и работа с чужим кодом, и тестирование, и работа с конкретным стеком технологий. Обучение одного курса заканчивается, студенты следующего курса получают тот же самый проект в исходном состоянии, и производят разработку по тем же задачам. Списать у предыдущего курса будет проблематично, потому что все пишут по-разному, и все равно надо понимать, как работает этот код.
Такие проекты можно придумать практически для любого набора языков и технологий — низкоуровневая разработка, десктоп + БД, веб-разработка. Или можно обратиться в IT-компании, чтобы подготовили что-нибудь подобное на основе своих старых проектов и задач по ним, то что разгласить не жалко. Лучше, конечно, если это будет введено более глобально, на уровне программы обучения, чтобы и до регионов дошло.
Я вроде бы обосновал свою точку зрения. Если у вас есть возражения относительно аргументов, прошу их озвучить. Мои аргументы на уровне — в реальности немного не так, как вы описываете.
> Но вижу и проблемы
Обозначьте, пожалуйста, эти проблемы. Я вас спрашивал об этом в личке, но вы ушли от ответа и сказали: «К сожалению никаких сохраненных ссылок не осталось, но помню, что по поиску в сети сразу выпадает несколько статей и дискуссий. Можно для затравки посмотреть обсуждение здесь».
Попробую предпринять последнюю попытку. Для вас в жизни при различении концепта стула и стола атрибуты имеют первичное значение. Независимо от того. что вы про эти атрибуты думаете. И у стула, и у стола есть 4 ножки и плоская поверхность. Предназначение плоской поверхности — это один из атрибутов. Можно сесть на маленький пенек и съесть пирожок, опираясь локтем на большой пенек, и поставив на него кружку с водой. В данном случае, маленький пенек это стул, большой пенек это стол, вне зависимости от количества ножек. То есть, функциональное предназначение — один из признаков.
А еще пенек — это оставшаяся часть дерева после спиливания. Этому признаку соответствуют оба пенька. То есть, мы не можем отнести объект к одной конкретной иерархии, у нас есть выбор, который делается на основе признаков ситуации и признаков сущности. И концепты — это всегда понятия, определяющие набор признаков. Иначе «концепты, относимые, к социальной, этической, эстетической областям» не могли бы быть представлены в виде реакции биологических клеток мозга приматов, которые (клетки) понятия не имеют обо всяких абстракциях.
> Остановимся на последней мысли подробнее. Например, некий индивид (нечто у меня в гараже) является автомобилем (фиксируется как подпадающий под концепт «автомобиль») не потому, что он соответствует некоторому перечню атрибутов (модели) концепта, а только потому, что я так решил, игнорируя то, что у этого индивида есть только одно колесо
Он соответствует вашему представлению об автомобиле. А для соседских детей автомобилем может быть кузов без руля и сидений, стоящий во дворе.
> индивид мул рождается мулом, существует как мул и умирает мулом, поэтому подпадает под концепт «мул»
Некоторое живое существо рождается как %entity%, существует как %entity% и умирает как %entity%. Вот эта %entity% подпадает под концепт «мул», «собака», или «комар»?
> Описание предметной области начинается с выделения объектов, и мы вынуждены это делать еще не имея никакой классификации, которую мы могли бы использовать в качестве шаблона для их различения.
Оу. Как же мы в обычной жизни-то различаем объекты, у нас же нет никакой классификации, которую можно использовать…
> нам не требуется проводить анализ, фиксировать атрибуты
Это еще почему? Вы не сможете отличить соседскую кошку, которую вы никогда раньше не видели, от соседской собаки, которую вы никогда раньше не видели? Думаю, что сможете, и сделаете это на основе ранее известных вам атрибутов, или признаков.
> с которыми и происходит сопоставление выделенного из среды индивида
Простите, а как оно происходит? Не на основе ли атрибутивного описания?
> Жучка пожизненно собака
Жучка пожизненно это живое существо с некоторым набором характеристик. Мы относим ее к собакам, потому что у нее есть некоторые известные нам признаки собаки. Кстати, мул это осел или кобыла?
> если бы эта (например) кошка не была бы кошкой, продолжала бы она существовать? Ответ отрицательный
Тут все верно. Кошка не была бы кошкой, потому что у нее была бы другая генетика. Кстати, возвращаясь к предыдущему примеру, если бы мул не был бы мулом, продолжил бы он существовать? А если бы он не был потомком мула?
> А если бы мы спросили, существовала бы студентка, не будь она студенткой? Ответ отрицательный
А тут неверно. Существовала бы школьница Маша, или секретарша Маша, но студентка Маша тоже бы не существовала, аналогично кошке. Потому что в этом случае Маша не подходит под описание того, что мы подразумеваем под понятием «студентка».
> А вот для разъяснении значения понятия «ездовая» потребуется указать на нарты и объяснить понятие «езда в упряжке», и лишь потом заключить, что Жучка «ездовая» потому, что она имеет отношение к «нартам» и «езде»
А для разъяснения понятия «лайка» нам надо указать на лайку и объяснить, какие именно параметры мы считаем принадлежностью лаек, и лишь потом заключить, что Жучка — лайка. Пример — две лайки разного окраса, и два щенка лайки и таксы одного окраса.
> Или, к примеру, человек подпадает под понятие «студент» не просто сам по себе, а только по причине наличия связи «персона – ВУЗ». Но мужчиной этот человек является имманентно – независимо от каких-либо отношений с другими объектами.
Ничего подобного. Студента мы определяем по одним признакам, мужчину по другим. Пример — некоторые лягушки могут менять пол. Другой пример — дожевые черви гермафродиты. Кто такие самка, самец, гермафродит? Как бы вы описали эти понятия?
> Вряд ли найдется такой аналитик, который сможет объяснить, что такое «ездовая собака» без ссылки на понятие «езда»
Понятие «ездовая собака» это само по себе связь между понятиями. Которое, кстати, обозначает некоторую характеристику — для чего может использоваться эта порода собак. Связь между сущностями вполне может быть самостоятельной сущностью. Даже само слово «связь» — существительное.
> Жучка подпадает под них просто по факту своего рождения: является животным, собакой и лайкой. И для того, чтобы это утверждать, не требуется обращаться к каким-либо другим понятиям, пояснять, что, кроме животных, есть еще и растения, что есть еще кошки и овчарки.
Ничего подобного. Если бы не было овчарок, никто бы не стал выделять понятие лайки, называли бы просто «собака».
На этом, пожалуй, можно закончить…
Неа. Здесь тоже идет соответствие признакам. К примеру, абсолютным чемпионом можно назвать победителя последней мировой выставки. Одна собака может несколько раз побеждать в выставках и соответствовать этим признакам, потом победит другая, и этим признакам будет соответствовать уже она.
Аналогично Жучка может перестать соответствовать признакам лайки, если набор признаков лайки поменяется, например, в результате какой-нибудь всемирной конференции биологов. Другой пример, можно считать банан деревом, а потом окажется, что это трава.
Потому что в наборах признаков собаки и кошки есть взаимоисключающие признаки, в данном случае связанные с генетикой.
Тут, конечно, есть отношение «часть-целое», но если рассмотреть это с другой стороны, то все снова сводится к набору признаков. У нас есть некоторое представление о том, что такое упряжка собак, и один из признаков — это некоторое множество собак. На привале собак можно распрячь и отпустить, тогда можно будет сказать, что у нас пустая упряжка.
То есть, все 3 случая — это соответствие определенному набору признаков. Может в теории традиционным является выделение множеств, но на практике выделение признаков давно уже применяется в программировании и проектировании предметной области приложения. Правда, там есть свои технические сложности касательно задания и определения соответствия, но это уже другой вопрос.
Я не сказал, что текст сложный, я сказал, что он дает неправильную информацию при объяснении особенностей. Конкретно:
— Про бэкенд. Из текста и из вашего комментария складывается впечатление, что бэкенд вторичен. На самом деле он «главнее», потому что в нем находится логика. Если на фронтенде нет проверок, а на бэкенде есть, проблем с данными не будет. А если на бэкенде нет проверок, а на фронтенде есть, то можно отправить неправильные данные вручную, без фронтенда. У вас в статье примерно то же самое, но акцент сделан не на том.
— Про intval. Тут вы поправили, но intval тут роли не играет. «echo 0123» тоже выведет 83. Это документированное обозначение 8-ричных чисел, так же как 0x123 обозначение для 16-ричных. Такое же обозначение используется, например, и в C++, и в Java, и в JavaScript. Из текста же складывается впечатление, что это какая-то фишка PHP, сходная с багом.
— Числа с плавающей точкой — проблема PHP. «Я говорил конкретно про PHP — в нём эта проблема есть». Это что-то вроде «у меня ваша программа не работает — так электричества же нет, поэтому компьютер не включается — ну и что, я же в вашей программе работаю».
— В проблеме с разрядностью про разрядность ничего не сказано. Не сказано, что в большинстве случаев такая разрядность не нужна, особенно в проектах начинающих. Если бы я не знал причину, у меня бы сложилось впечатление, что это опять какой-то косяк PHP.
А текст является разновидностью байтов. Это не значит, что надо с любыми данными работать как с байтовым массивом. У вас как-то все сумбурно — как будто разметка это разновидность перевода строк.
Там написано, что я с этой проблемой не сталкивался, я не сказал, что ее не существует. Вообще это был своего рода намек «Уважаемый автор, не расскажете ли вы, с какими именно задачами вы столкнулись, что там переводы строк это серьезная проблема. Я вот не сталкивался, вдруг понадобится, хоть буду знать». У вас половина статьи о том, что это важно, но нет никаких примеров, которые бы эту проблему иллюстрировали. Пара неправильно отформатированных строк это не примеры, потому что непонятно, как они появились.
Наоборот, фронтенд обязан повторять расчеты бэкенда. Вернее даже не так. Фронтенд может повторять проверки бэкенда — для ускорения работы и улучшения UI, а может и не повторять. На бэкенде все проверки всегда должны быть в полном объеме.
Насколько я знаю, браузеры вполне неплохо сами разбираются с разными переводами строк. В любом случае, это исправляется простой заменой разных переводов строк на нужные в функции получения данных из файла.
Не надо путать текст и HTML. Если в файле есть <br>, значит это разметка, и не надо работать с ней как с текстом. Если разметка расположена вперемешку с текстовыми файлами, значит это проблема в архитектуре конкретного проекта. Исправить можно аналогично, через замену по регулярному выражению. Переводы строк тут ни при чем.
Это ошибка только в форматировании вывода. Любая замена переводов строк эту проблему не решит.
Выведет 123. Кстати, вам надо было поставить там ссылку на документацию по intval() (заодно и сами бы почитали).
Если записать без кавычек, то будет 83, но это уже изначально int, записанный в 8-ричной системе. Это аналогично записи 0x123 без кавычек для 16-ричной. Лидирующие нули в строках на результат не влияют. А для преобразования string в int лучше использовать приведение типов "(int)$var".
PHP здесь ни при чем, так происходит во всех языках, это особенность представления таких чисел в процессоре.
Откуда у INT дробная часть?
«Что бы полностью понять суть проблемы», надо знать, что такое разрядность. Да и вообще, для большинства таблиц простого INT хватает. Не собираетесь же вы в каждой таблице по 3 миллиарда записей хранить?
Рекомендуют использовать htmlspecialchars().
Не знаю, что за задачи этого требуют, лично я ни разу не сталкивался. Обычно что сохраняем, то и выводим, плюс экранирование. Для javascript можно выводить через json_encode().