«Табы занимают меньше места» — это какое-то типичное мнение любителей пробелов о тех, кто предпочитает табы.
Я предпочитаю табы, но размер — это простите последнее о чем я вообще могу подумать в качестве аргумента «за». Более того — я предпочту не использовать этот аргумент, т.к. он — глупый.
Классической историей считается требование группе Скорпионс оплатить 5% от сборов в пользу себя же, но в адрес РАО, хотя до того аналогичная история происходила и в октябре 2008 года с английской группой Deep Purple в Ростове-на-Дону.
Ну вообще и в первом и во втором случае это были разумеется иски к российским организаторам концертов, а не к группе. Суть притензии сводилось к тому, что вознаграждение артистам как исполнителям выплачено было, а как авторам — нет. (И кстати исполнитель не всегда автор).
Так же было и в случае с ветеранами, когда притензии предъявлялись к организаторам. Да вообщем притензии всегда к площадке, а не к исполнителю.
Я понимаю, что у людей неоднозначное отношение к вопросу авторских прав и они могут нравится или нет, но пишите правду.
Не наступйте на больное — сам жду. Вопрос в том, что если те фичи с которыми все примерно ясно не вошли, то про рефлексию compile/runtime и вовсе заикаться неудобно.
И ведь даже если к след. станадрту введут хотябы одну из ожидаемых фич, то "вау" уже не будет. Будет: "Спасибо конечно, что сделали фичу, которая нам нужна была 5 лет назад". Одно разочарование. Вхождение в стандарт концептов уже почти похоже на выход Half-Life 3.
По собственному опыту могу сказать: очень нравится когда человек хорошо оценивает свои знания и очень не нравится, когда соискатели в своем резюме пытаются указать, что являются специалистами во всех технологиях о которых слышали.
Список технологий из резюме студента часто выглядит так: «MySQL, Postgres, Oracle, MsSql, css, html, javascript, php, C/C++, Rust, Golang, XML, Pascal, Delphi, Python, Java ...»
Резюме профессионала часто содержит в себе самый минимум того в чем он действительно разбирается. При этом о многих побочных (для него) технологиях он имеет хорошие средние знания.
Если человек заявляет, что он специалист в технологии X, а сам путается в основах — это крупный минус.
Если человек говорит, что он «с этой технологией не очень много работал», но выдает уверенные знания по теме с ньюансами, то это жирный плюс. Даже если он чего-то про это не знает — то это не будет минусом — он же не заявлял себя специалистом в этой технолгии.
Спасибо за изыскания. В качестве комментария замечу, что есть на мой взгляд лишние технические подробности. Вопроса кода касаться не буду.
Вопрос о собественном опыте.
Соглашусь про Wt. Он прикольный, но на мой взгляд категорически непрактичный. Результирующая страница получается очень сложная и происходящие внутри процессы (особенно в плане взаимодействия с сервером) становятся слабо понятными. В целом и работает это не очень бодро, т.к. слишком сложно и слишком универсально.
К слову говоря, оберунть сишную FCGI либу в удобный лично для вас С++ сахар — это достаточно быстрый процесс. Просто, сурово и прозрачно, а главное — минималистичный интерфейс.
Лично мне последнее время более интересны JS Клиент + Сервер на Websocket. Если не нужно поддерживать всякие там IE6, то уже вполне с этим можно работать. Очень кажется, что все идет именно в этом направлении. Есть кстати вполне годная библиотека на эту тему.
Родительское private свойство можно переопределить в потомке как public
Это будет другой член класса с таким же именем. Это назвается shadowing (затенение). Точно так же во многих языках допускается shadowing внутри scope. К разговору о доступе это отношения не имеет.
«Модификаторы доступа» — общепринятая концепция, которая ограницичает доступ, а не видимость. То что «создание свойств на лету» (частное свойство языка) является более приоритетным, чем общепринятая концепция — это большая беда и болезнь языка.
В PHP используется термин «Visibility», хотя в большинстве языков используется термин «Access Modifiers». Удивительно, но даже в документации PHP речь идет про «access», хотя в заголовке написано про «visibility». Удивительная подмена понятий: говорим про «видимость», а рассказываем про «доступ».
В документации на php я нашел ровно этот случай с пометкой значения значения как «Undefined». Так что правильно или нет — вопрос вкуса. С точки зрения документации — да. С точки зрения логики и общепринятой практики — это большой вопрос.
Если вы считаете, что раз оно в PHP так, то это правильно, я не имею возможности с вами спорить. Нет логической возможности для оспаривания аксиоматических утверждений. Есть «модификаторы доступа», которые появились задолго до PHP. Есть практика их использования, есть разговор про «доступ», а не про «видимость». Если создадут язык в котом слово «class» означает объявление строки, а слово «public» — выделение места на куче, то сложно будет поспорить с тем, что это особенность языка.
Мы с вами говорим об одном и том же, с той только разницей, что я ставлю знак "-", а вы — знак "+".
Я попробую показать еще один пример: если вы попробуете использовать рефлексии, то
$api = new ReflectionClass($f);
foreach($api->getProperties() as $p) {
print $p->getName() . "\n";
}
даст вам разные результаты для private и protected, хотя и в том и в другом случае доступа к члену класса нет. Я имею ввиду пример с B extends A.
То есть вы порефакторили класс — только изменили область видимости и изменили логику работы программы. В C++ или Java я могу быть точно уверен, что логика работы от замены private на protected или наоборот не изменится. Мой код может не скомпилироваться — это верно, но работать он будет так же.
А я не люблю Python. И сказать про него много не могу. Но я же здесь не про Питон разжигаю, а про ПХП. На JS немного пописал — это тоже не мое. Но там ведь я не припомню private. Вообщем по поводу перечисленных яызков — возражений не имею.
Речь про то что видно снаружи.
В пример в классе Foo его видно, но он не доступен.
А в классе Bar его уже не видно снаружи.
В частности это имеет значение при использование рефлексии. При изменении области видимости вы можите получить разные результаты (хотя это могло поменяться, но с учетом описанного выше, думаю что нет).
да нет, в наследуемом классе оно уже не private, иначе к нему он тоже мог бы обратиться.
Хорошо — я выразился не вполне верно. С точки зрения пользователя (а пример рассматривается с точки зрения пользователя) ничего не поменялось. Он как не мог обратиться к этому полю — так и не может. Поле не исчезло. Проведите подобный эксперимент в других языках.
Как вы правильно заметили — правильно было бы иметь одинаковое поведение.
Вы не вполне понимаете. От того, что произошло наследование, поле «foo» не стало «более private». Оно было унаследованно и осталось private. Как и было. ничего не поменялось. Точнее «ничего не должно было поменяться». Однако поменялось. Мембер только что «был, но к нему нельзя было обратиться», а теперь «исчез».
Как вы думаете: «наступал» я на это ли нет, раз пишу об этом?
Это средство контроля — не средство изменения логики. В С++ так и есть. И в Яве тоже.
Скомпилированный код на С++ с разными областями видимости (если оно скомпилировалось) ничем бинарно не отличается.
Потому, что область видимости означает, что «к члену класса нельзя обратиться», а не то, что «этого поля никто не должен видеть». Такая реализация приводит к изменения логики работы программы при изменениии области видимости. Это не в какой ООП простите не лезет.
Я предпочитаю табы, но размер — это простите последнее о чем я вообще могу подумать в качестве аргумента «за». Более того — я предпочту не использовать этот аргумент, т.к. он — глупый.
Ну вообще и в первом и во втором случае это были разумеется иски к российским организаторам концертов, а не к группе. Суть притензии сводилось к тому, что вознаграждение артистам как исполнителям выплачено было, а как авторам — нет. (И кстати исполнитель не всегда автор).
Так же было и в случае с ветеранами, когда притензии предъявлялись к организаторам. Да вообщем притензии всегда к площадке, а не к исполнителю.
Я понимаю, что у людей неоднозначное отношение к вопросу авторских прав и они могут нравится или нет, но пишите правду.
То есть больше стало? Или ошибка?
Список технологий из резюме студента часто выглядит так: «MySQL, Postgres, Oracle, MsSql, css, html, javascript, php, C/C++, Rust, Golang, XML, Pascal, Delphi, Python, Java ...»
Резюме профессионала часто содержит в себе самый минимум того в чем он действительно разбирается. При этом о многих побочных (для него) технологиях он имеет хорошие средние знания.
Если человек заявляет, что он специалист в технологии X, а сам путается в основах — это крупный минус.
Если человек говорит, что он «с этой технологией не очень много работал», но выдает уверенные знания по теме с ньюансами, то это жирный плюс. Даже если он чего-то про это не знает — то это не будет минусом — он же не заявлял себя специалистом в этой технолгии.
Вопрос о собественном опыте.
Соглашусь про Wt. Он прикольный, но на мой взгляд категорически непрактичный. Результирующая страница получается очень сложная и происходящие внутри процессы (особенно в плане взаимодействия с сервером) становятся слабо понятными. В целом и работает это не очень бодро, т.к. слишком сложно и слишком универсально.
К слову говоря, оберунть сишную FCGI либу в удобный лично для вас С++ сахар — это достаточно быстрый процесс. Просто, сурово и прозрачно, а главное — минималистичный интерфейс.
Лично мне последнее время более интересны JS Клиент + Сервер на Websocket. Если не нужно поддерживать всякие там IE6, то уже вполне с этим можно работать. Очень кажется, что все идет именно в этом направлении. Есть кстати вполне годная библиотека на эту тему.
Это будет другой член класса с таким же именем. Это назвается shadowing (затенение). Точно так же во многих языках допускается shadowing внутри scope. К разговору о доступе это отношения не имеет.
В PHP используется термин «Visibility», хотя в большинстве языков используется термин «Access Modifiers». Удивительно, но даже в документации PHP речь идет про «access», хотя в заголовке написано про «visibility». Удивительная подмена понятий: говорим про «видимость», а рассказываем про «доступ».
В документации на php я нашел ровно этот случай с пометкой значения значения как «Undefined». Так что правильно или нет — вопрос вкуса. С точки зрения документации — да. С точки зрения логики и общепринятой практики — это большой вопрос.
Если вы считаете, что раз оно в PHP так, то это правильно, я не имею возможности с вами спорить. Нет логической возможности для оспаривания аксиоматических утверждений. Есть «модификаторы доступа», которые появились задолго до PHP. Есть практика их использования, есть разговор про «доступ», а не про «видимость». Если создадут язык в котом слово «class» означает объявление строки, а слово «public» — выделение места на куче, то сложно будет поспорить с тем, что это особенность языка.
Я попробую показать еще один пример: если вы попробуете использовать рефлексии, то
$api = new ReflectionClass($f); foreach($api->getProperties() as $p) { print $p->getName() . "\n"; }даст вам разные результаты для private и protected, хотя и в том и в другом случае доступа к члену класса нет. Я имею ввиду пример с B extends A.
То есть вы порефакторили класс — только изменили область видимости и изменили логику работы программы. В C++ или Java я могу быть точно уверен, что логика работы от замены private на protected или наоборот не изменится. Мой код может не скомпилироваться — это верно, но работать он будет так же.
Но мы пришли к тому с чего начали
и что в PHP
Мне кстати более таких языков не известно — наверное я их не очень много знаю.
В пример в классе Foo его видно, но он не доступен.
А в классе Bar его уже не видно снаружи.
В частности это имеет значение при использование рефлексии. При изменении области видимости вы можите получить разные результаты (хотя это могло поменяться, но с учетом описанного выше, думаю что нет).
ideone.com/D9V4Rx
Хорошо — я выразился не вполне верно. С точки зрения пользователя (а пример рассматривается с точки зрения пользователя) ничего не поменялось. Он как не мог обратиться к этому полю — так и не может. Поле не исчезло. Проведите подобный эксперимент в других языках.
Как вы правильно заметили — правильно было бы иметь одинаковое поведение.
Как вы думаете: «наступал» я на это ли нет, раз пишу об этом?
Скомпилированный код на С++ с разными областями видимости (если оно скомпилировалось) ничем бинарно не отличается.