- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
<?php
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
if($_POST['SESS_PARAM'] && $_POST['SESS_PARAM'] !='' && $_POST['SESS_PARAM_VALUE'] && $_POST['SESS_PARAM_VALUE'] !=''){
$_SESSION[$_POST['SESS_PARAM']] = $_POST['SESS_PARAM_VALUE'];
echo 'ok';
}else{
echo 'error';
}
Follow us!
быстро скажи что-нить умное
это я узнал пароль от ракоучётки
почему-то он кажется подозрительно знакомым))
Какое аниме посоветуете?
Посоветываю: Naruto, Dragon Ball Z, Boruto: Naruto, Pokemon, One Piece, Boku no Pico.
class Boruto: public Naruto
Потому что наследование ради реализации это пидорство?
Но вообще отсутствие классов делает многие вещи проще
* проще делается ОРМ
* не нужно думать про вызовы деструкторов
А вообще да: жабаскриптерские петушки пятьнадцать лет кукарекали нам о прелестях прототип-ориентированного ООП.
--у вас в JS нету классов
--ко-ко-ко, у нас есть прототипы, это намного лучше, ты просто не умеешь ими пользоваться
При этом в каждой библиотеке был свой способ наследования.
А потом в js завезли "class", и министерство правды сказало, что классы это хорошо.
И петушки развернулись на 180 градусов.
Такая же хуйня у скриптопитушков происходит со стат типизацией
В жабе тоже есть finalize, а в C# finalize и ~, но когда они вызовутся, и вызовутся ли вообще -- этого никто не знает.
Для JVM Шипилёша вообще напилил такой GC, который никогда не вызывается. Сколько памяти сначала есть, столько и будет (забыл, как этот "GC" называется).
Так вот:
A FinalizationRegistry object lets you request a callback when an object is garbage-collected.
А когда? Когда рак на горе свиснет.
Ну и чтобы отсос был особенно полным, прямо на мозиле написано
A conforming JavaScript implementation, even one that does garbage collection, is not required to call cleanup callbacks.
трудно пройти мимо скриптоблядей, и не обоссать их. Сами понимаете..
Так вот. Деструкторы позволяют освобождать ресурсы детерменированно. В языках для анскильных обезъян (типа джавы, котлина и C#) деструкторов по сути нет, потому они пилят свои using, и closable disposable.
В то время как программисты на нормальных языках (типа C++) смотрят на них как на идиотов
Ты создал объект, который отражает какую-то структуру в операционке (ну там GDI в винде или это слушающий сокет в классе, представляющем сервер)
В С++ можно каждый внешний ресурс обернуть в класс. Да, кода придется писать много (хотя бывают готовые шаблоны), но зато ты точно будешь знать, что кода объект умрет -- ресурс закроют.
А джавабляди вручную управляют ресурсами, как в сишечкеи
https://plugins.jetbrains.com/docs/intellij/disposers.html
Ну, допустим, он нужен почти всё время работы программы, но не совсем всё. Поэтому внутри одной функции заточить его не получается.
имелись в виду конечно методы класса, иначе зачем там дырка? при чём конструкторы?
Вот на С++ у меня есть класс, в констркторе которого открывается сокет, а в десутркторе закрывается.
У него так же есть метод "послать в сокет говна".
Я создал объект класса, попользовался им сколько нужно, и он потом уничтожлился, и закрыл сокет.
Причем если я не дурак, и не пользовался new, то скорее всего он уничтожится сам (и сокет закроется)
как мне это сделать на жабе?
в Свифте у меня может быть объект, который конструируется in place (проперти сразу присваивается значение) или какой-нибудь lazy. Если у него в ините сидит открытие ресурса, которое может по какой-то причине тупить, то будет и не приятно, и не очень детерминировано
не понял, что неприятного в открытии ресурса в конгструкторе, пусть и тупящего.
Это явно лучше, чем отдельный метод open, добавляющий в объект лишний state
>и не очень детерминировано
Почему?
К моменту создания объекта ресурс открыт, всё логично
мне так не лучше
закрыли тему
заебали со своей жабой блять
почему ты против открытия сокета или файла в конструкторе?
2) в языках вроде Свифта инициализация поля может пройти в разных местах в разное время, отсюда некая недетерминированность
3) открытие ресурса не есть ИМХО логикой инициализации (только не надо про raii), а потому должно быть вынесено из инициализации - семантически мне так нравится
ты удовлетворён?
2. то есть ты не знаешь, когда будет вызван конструктор?
3. почему не надо по raii?
2) в целом знаю, но это может быть неявно выражено в коде
3) потому что это чисто крестовая приблуда, которая к другим языкам не применима
В общем случае не существует требования "инициализация должна быть быстрой".
Однако есть фреймворки, которые требуют быстрого создания объекта (например, потому что он создается на UI треде).
Это особенность фреймворка, но не общее правило.
2) и что плохого в том, что в какой-то момент создастся объект и сделается запрос?
3) ну вообще RAII не привязана к конкретному языку, и кажется, что в языках с RC она тоже может быть реализована.
4) в логике фреймворков типа UIKit создание некоторых объектов и назначение этим объектам неких ресурсов разнесены во времени, как и обратные действия
гораздо хуже вводить в обект лишнее состояние, и делать его мутабельным
тогда мы друг друга не поймём
пойду поем
Кстати, это всё сильно зависит от ЯП, в жабе, например, хуй что в конструкторе сделаешь, потому что там крайне не рекомендуется бросать исключения (а в йаже почти всё их кидает).
Скорее уж не рекомендуется это делать в С++, потому что у тебя пол объекта будет инициализирвано, а деструктор не вызовется.
Потому в С++ принято (ну, насколько я могу судить) оборачивать в классы каждый ресурс
Да и похуй. У полей и локалок, которые прошли инициализацию, деструктор вызовется.
Я имел ввиду, что нельзя например сделать такой класс с двумя полями, каждое из которых представляет из себя внешний ресурс, и открыть их оба в конструкторе не ловя исключение и не обрабатывая явно обсёр с открытием.
А ты что думаешь про нашу дискуссию с Десктопом, кстати?
Вай нот, если он не дефолтный. Ничему особо не мешает.
У меня есть класс, представляющий вебсайт. В него зашит урл сайта (красоту хардкода пока оставим за скобками). При создании объекта он всасывает в себя сайт.
Я серьезно не понимаю, почему так нельзя. Конечно, если нет требований фреймворка "создавать объект быстро"
Хотя бы фейковый аргумент надо, имхо.
Если это не так, лучше его убрать. Зачем расставлять грабли.
Я вот ожидаю, что объект после создания будет в инициализированном состоянии, готовом к использованию.
Иначе зачем мне раии?
Его просто слишком легко позвать не подумав.
Скорее всего ты говоришь с позиции С++сника, где невинное
может вызвать бурю.
В языках где объекты живут в куче и управляются только через укатазатель, таких проблем нет.
Трудно "случайно" написать
Если мы так боимся случайного вызова, то можно сделать приватный конструктор, и фабричный метод. Но тогда нужно думать про мувы и копирования всякие
Фейковый аргумент костыль конечно, но я реально не помню чтобы у меня был тяжелый конструктор, у которого не было бы аргументов.
> фабричный метод
Ну тоже норм.
Но такие объекты должны быть синглтонами конечно, а не создаваться на каждый чих
>Ну тоже норм.
если делать фабоичный метод, так это надо мув семантику разрешать тогда, не?
А всякие ResourceLoader да VideoAdapter тяжёлую работу скорее всего в методе делать будут. Ибо менять разрешение на ходу или загружать следующий уровень захочется. Странно это делать в дефолтном конструкторе.
А загруженный уровень можно выкинуть вместе с текстурами, но в такой класс конечно нужно передавать как минимум номер уровня
В общем я понял поинт: никаких особых правил в целом нет, но тяжелый дефлотный конструктор будет выглядеть странно и подозрительно, потому что так обычно не делают
- никогда больше такого не говори никому
На компьютере есть как правило один видеоадаптер. Какой смысл иметь несколько объектов для работы с ним?
Если тебя смущает, что время жизни синглтона не определено, то можно конечно хранить его на стеке main, например. Он явно разрушится, когда завершится main.
Но это всё равно будет один объект
- возьми любой практически ширпотребный ноутбук и пойми, как ты ошибаешься
> Какой смысл иметь несколько объектов для работы с ним?
- не с ним, а с ними
я видел приложения, которые все были по уши в синглтонах, а потом не могли открыть два документа одновременно
синглтон не просто так считается анти-паттерном
Мы говорили об игре. Трудно представиь себе игру, которая работает одновременно с двумя видеоадаптерами, выводя на них разную картинку. Но если такая задача встанет, то конечно никаких синглтонов.
>а потом не могли открыть два документа одновременно
Это проблема неверного использования синглтона.
>синглтон не просто так считается анти-паттерном
Кем считается?
- кто сказал про ОДНОВРЕМЕННО? Ты зашёл в настройки и переключил рендеринг на другой адаптер. А у него УЖЕ ЕСТЬ объект, настроенный на работу с ним (ну или ты его создал из фабрики).
> Это проблема неверного использования синглтона.
- у синглтона практически нет примеров верного использования, кроме каких-то application wide настроек, и то
>кроме каких-то application wide настроек
Вполне себе хороший пример.
Довольно очевидно, что синглтон нужен только тогда, когда на всё приложение тебе нужен только один объект.
В каких именно случаях это нужно -- вопрос к дизайну приложения.
- какая разница, мы про техническую возможность. А ты как уж на сковородке)
Ты привел пример противоположной ситуации.
Разумеется, синглтон (как и любой другой паттерн) не универсален.
Игра может вообще иметь интерфейс с доступом по сети, и тогда класс для видеоадаптера ей не нужен, однако это не значит, что такой класс не нужен никогда
> Игра может вообще иметь интерфейс с доступом по сети
- В большинстве своем сальпы и огнетелки очень теплолюбивы, поэтому встречаются только в экваториальных и тропических водах. Лишь несколько видов живут в полярных районах. К тому же животные эти очень требовательны к солености воды, они обитают только в тех морях и частях океана, где она составляет 33—35 ‰. В Восточном Средиземноморье, где соленость доходит до 40 ‰, а также в местах впадения рек, где она понижена, сальпы и пиросомы не живут.
Синглтон в Intellij Idea, например:
https://github.com/JetBrains/intellij-community/blob/master/platform/core-api/src/com/intellij/openapi/application/Application.java
Твое утверждение "синглтон не нужен" неверно.
Остальное мне трудно прокомментировать
> Твое утверждение "синглтон не нужен"
- покажи, где такое утверждение? есть редкий класс задач, где он полезен. в остальном это анти-паттерн.
[quote]
синглтон не просто так считается анти-паттерном
[/quote]
Из определения антипаттерна следует, что
Another solution to the problem the anti-pattern is attempting to address exists, and documented, repeatable and proven to be effective where the anti-pattern is not
Иными словами, антипаттерн всегда можно заменить на более верное решение.
А в данном случае вряд-ли существует более верный solution, так что singleton антипаттерном не является.
>есть редкий класс задач, где он полезен. в остальном это анти-паттерн.
Любое решение подходит для одного класса задач, и не подходит для другого. Это не делает его антипаттерном.
Действительно, задач для синглтона немного, но они есть.
Возвраясь к примеру с игрой: если игра при запуске настраивает видеоадаптер, а при завершении возвращает настройки, и перенастройку не поддерживает (большинство игр, выпущенных до второй половины 90-х, смену разрешений не поддерживали, например) то синглтон является вполне допустимым представлением видеоадаптера
- конечно является
> Это не делает его антипаттерном
- конечно делает
> вряд ли существует более верный solution
- класс Application это прибитый гвоздями обработчик системных событий, программисту апи-пейсатели так прямо и говорят: у тебя, шакалёнок, может быть только один, сука, обработчик. Более верный solution? Помогите Даше найти
> большинство игр, выпущенных до второй половины 90-х, смену разрешений не поддерживали
- как обычно, в ход пошли какие-то примеры, которые не имеют ни малейшего отношения к обсуждаемой теме. В такой момент становится понятно, что аргументы Макаки иссякли :-)
спасибо, я всё! доброй ночи
нет
> - конечно делает
нет
> класс Application это прибитый гвоздями обработчик системных событий
нет, это API для доступа к приложению. Я же дал ссылку.
>как обычно, в ход пошли какие-то примеры, которые не имеют ни малейшего отношения к обсуждаемой теме.
Ты сообщил, что singleton это антипаттерн, я привел пример его использования.
> В такой момент становится понятно, что аргументы Макаки иссякли
написал человек с аргументами
"- конечно является" и "- конечно делает"
>доброй ночи
доброй ночи
- так это я тебя косплеил, твой стиль) всё, ушёл
Мне кажется, что ты рассматриваешь вопросы с точки зрения IOS программиста.
В IOS действительно нет никакого смысла держать в памяти необновляемый список билетов, потому что приложения там вообще не перезапускаются по желанию пользователя (и вроде бы вообще могут работать сутками не выключаясь)
Работа с HTTP там так же реализуется через фоновый поток (делается ли это через GCD или по другому -- не важно, важно, что это не делается на main).
Но такие приложения это только небольшая часть всего софта, что пишут люди, и приемы, которые недопустимы в IOS, вполне могут быть допустимы в других областях.
Потому что в разных областях допустимы разные приемы.
К примеру, jциферки или Борманд может писать в порты оборудования напрямую, а фронтэндер bootcamp скорее всего так делать не будет никогда, и вероятно ты в IOS тоже не будешь.
Это, однако, не значит, что работа с оборудованием напрямую это антипаттерн.
Досвидания
используй статические методы "класса" и теки
Чем меньше стейтов есть у объекта -- тем лучше. В идеале он один. Не понимаю, как это противоречит ооп
не хочешь стейт, не бери ООП
ООП это про объединение в одной сущности данных и методов для работы с ними.
Хрестоматийный пример ООП, просто из палаты мер и весов: получает все параметры в конструкторе, имеет только один стейт, и никогда его не меняет
- тебе на работе платят за копипасту хрестоматийных примеров из википедии или всё же за реальный осмысленный код?
или ты только с DTO и работаешь?
Мне платят за реальный код, в котором бОльшая часть классов получает свой стейт в конструкторе и иммутабельна. Это никак не мешает мне работать с ООП.
с другой стороны, судя по всему, на такой работе остаётся много времени, чтобы, например, обсирать "бойлерплейт" в Джаве
Какая вообще связь?
я привел пример иммутабельного класса.
Если тебя смущает недостаточное количество логики, то вот тебе классическая стратегия
никакого стейта нет, а ооп есть.
ООП не требует, чтобы классы имели мутабельный стейт.
- покажешь где?
если я неверно тебя понял, то объясни пжлста, что ты имел ввиду.
если тебе нужны тупые данные без состояний, то бери язык без ООП, хуярь в нём структуры и обрабатывай при помощи чистых функций. зачем тебе ООП?
если бы у бабушки были...
В таком случае у объекта будет одно состояние: инициализирован ответом, вот этот ответ в поле лежит.
Если я сделаю для запроса отделтный метод, то у объекта будет два состояния:
* запрос еще не сделали, и в поле лежит хуй (null? пустая строка? что там должно быть?
* запрос уже сделали, и в поле лежит ответ
Каждый метод объекта будет обязан проверять стейт, это сильно усложнит работу объекта.
Не говоря уже о том, что это сделает его не потокобезопасным
> Не говоря уже о том, что это сделает его не потокобезопасным
- пошла софистика
Объект не создастся, и проблемы не будет.
>>потокобезопасным
>- пошла софистика
Верно ли я понимаю, что тебе не приходилось сталкиваться с вопросами потокобезопасности? Если приходилось, тогда что ты имел ввиду, говоря о софистике?
- если ты видишь что-то непотокобезопасное, а тебе его надо сделать потокобезопасным, сделай. Любой нормальный язык тебе даёт всё для этого. К теме разговора это отношения не имеет
Объект, имеющий мутабельный стейт, нужно синхронизировать, так изменяемые поля могут оказаться в неизвестном состоянии при обращении к ним.
Если же все поля установлены в конструкторе, то к созданнмоу объекту можно смело обращаться из любого потока.
Если потом видит объект, то он видит и все его поля
Что не так?
второе. а ты типа собрался хттп-запрос делать из того же потока, в котором конструктор позвали? то есть, вызвали на main, всё, блочим UI? или всё же как-то асинхронно, что эффективно делит на ноль все твои соображения об иммутабельности?
или ты щас скажешь, что async/await есть в каждом мейнстримовом языке?))
не очень понятно причем тут это. Если объект впринципе может изменять свое состояние, значит в каждый конкретный момент соседний поток состояния этого не знает, и обращение к полям нужно синхронизировать, иначе будут гонки.
> а ты типа собрался хттп-запрос делать из того же потока, в котором конструктор позвали?
Да.
>то есть, вызвали на main, всё, блочим UI
Объект ничего не знает о том, в каком потоке его будут вызвать.
Существует огромное количество ситуаций, когда поток можно блочить: это фоновая обработка задач, работа в командной строке, в сценарии, итд.
Если фреймворк запрещает медленные конструкторы, но конечно ничего загружать в них нельзя, о чём я почти сразу и написал:
[quote]
Однако есть фреймворки, которые требуют быстрого создания объекта (например, потому что он создается на UI треде).
[/quote]
в общем, если ты вдруг будешь писать UI, попробуй сделать именно так: отправить хттп-запрос из конструктора в похуй каком потоке, сделай ревью.
Интересно будет почитать причитания о том, как злые коллеги не хотят его апрувить)
Если я внесу в такой класс знания о UI потоке, то на ревью его скорее всего завернут.
тебе надо знать про поток выполнения. а он должен быть специальным для работы с сетью. Именно для того, чтобы не блокировать пользовательский интерфейс.
Второй способ более универсален, так как кроме UI приложений, есть еще и другие приложения.
это правда где-то может сойти за адекватное решение, кроме наколеночного скрипта?
Так работают очень многие утилиты командной строки, например.
Разумеется, делать так UI нельзя. Это требование фреймворка (всех фреймворков для работы с UI), о чём и было сказано изначально
а "энтерпрайз приложение" где здесь?
не понятно, почему интерфейс вывода (командная строка, ui, web итд) должен как-то влиять на использование или не использование ООП
>а "энтерпрайз приложение" где здесь?
В энтерпрайз приложении задачи могут выполняться в фоновом режиме, как по крону.
Такая задача создает объект, который в конструкторе получает нужные данные, производит с объектом какие-то действия, и завершается.
При следующем запуске она снова создаст объект.
- это если они у тебя есть. Вообще кидать исключение в вашей жабе на request timeout это хорошая практика? Или на отсутствующее соединение?
Кинуть бизнеслогическое исключение из конструткора вполне нормально, имхо.
Если бы я вынес загрузку билетов в отдельный метод, то в методе findTickets() мне бы пришлось проверять, что перед ним был вызван нужный метод загрузки.
а твой findTickets() работает со старыми
чтобы работать с новыми, нужно пересоздавать объект
такой себе пример
Работать с таким объектом проще, чем с тем, где нужно не забыть после конструктора вызвать еще и fetchTickets();
> Работать с таким объектом проще, чем с тем, где нужно не забыть после конструктора вызвать еще и fetchTickets();
- конечно проще, ведь он нихуя не умеет.
> ведь он нихуя не умеет.
Он умеет найти нужный билет, отсортировать билеты, и представить их в нужной форме.
Ты опять пытаешься мне рассказать, что объект без изменяемого стейта должен нихуя не уметь.
Это не верно.
твой клиент хочет обновлять список билетов раз в час
то, что билеты на сервере обновляются раз в три минуты, твой клиент ни капли не чешет
пользователи пишут гневные письма в поддержку, а Макака им отвечает: да всё мы умеем, не сцыте!
Если же он работает в долго живущем приложении, то вполне можно пересоздать объект
пример с загрузкой информации про билеты это обычно работа для тонкого клиента.
так вот, у тонкого клиента обычно нет никакого глобального состояния, но его компоненты в отдельный момент времени могут иметь состояние, чтобы корректно отобразить интерфейс, и обновлять его.
Ты же предлагаешь в тонком клиенте иметь глобальное состояние (список билетов, затянутый по таймеру), которое может быть некорректным, что критично для пользователя и бизнеса. При этом ты категорически отказываешься от состояния в компонентах, просто потому что "это сложно".
ну ок, чо.
в скрипте с названием "tickets". Какая разница -- в каком?
>это обычно работа для тонкого клиента.
Это может быть работа энтерпрайз приложения в фоновом режиме с посылкой результата по email.
>Ты же предлагаешь в тонком клиенте иметь глобальное состояние
Где я говорил что либо про тонкий клиент?
>При этом ты категорически отказываешься от состояния в компонента
Где я говорил что либо про компоненты?
Разумеется, работающее десктопное или мобильное приложение должно подтягивать билеты без перезапуска, но из этого никак не следует, что "объекты без изменяемого состояния не нужны".
Потому что кроме UI компонента такого приложения бывают еще и другие объекты.
Приложение выполняет задачу
* создает объект, который подтягивает список билетов
* находит в них нужный
* отсылает сообщение по email
В каком месте тут будут некорректные данные?
Лол
тебе бы в питоноблядство, чувак:)
https://www.hyrumslaw.com/