Ну как не меняете, а как же смена экрана (одной xml на другую) иначе интерфейс был бы статическим и причина не в отзывчивости. Вы всё-равно вызываете какой-то метод на Java/Kotlin/C#/C++, чтобы поставить другую xml на вьюхе. Опять таки всё абсолютно так же.
По поводу поисковых роботов, как бы уже всё-равно они умеют в JS и т.д. с хитростями, но всё же. Например, текущий GoogleBot работает на базе Headless Google Chrome 80 и начиная с прошлого месяца он EverGreen т.е. обновляется синхронно с бразуером. У Яндекса так же +-.
SSR нужен в первую очередь не для роботов, а для людей со слабым интернетом, чтобы они не ждали весь клиентский JS код и когда код отрисует содержимое, а уже могли видеть контент.
А причина переноса всего фронтенда (клиент и сервер) на JS в желании оптимизировать разработку, ведь это удобно, когда один и тот же код работает как на клиенте, так и на сервере. И к этой оптимизации уже с 2015 года некоторые пришли.
Вообще вся эта ветка комментариев это просто "Раньше было лучше" и "В наше время" и применить это можно к чему угодно, хоть к появлению языка Swift или Kotlin. Но время идёт, меняются реалии, цели, задачи.
Я на html могу сделать нормальный статичный сайт без всякого js и он будет отлично отображаться и работать.
Отображаться да, работать зависит от ваших нужд, для работы форм у вас всё-равно должен использоваться какой-то язык программирования на стороне сервера. Для только гипертекста этого действительно хватит.
Но если у меня html+js то отключение js приводит к показу печальной таблички ой у вас отключен js.
Это зависит от того как вы реализуете свой сайт HTML+JS, если используете прогрессивные методы, то в случае отключения JS просто откатитесь до HTML-only, который как вы чуть раньше указали будет работать без всякого JS. А вот если вы делаете SPA со 100% отрисовкой на клиенте, то да будете показывать табличку.
Опять же если в нативных приложениях дать возможность отключать язык программирования, сохраняя только разметку XML — получите эту же ситуацию, вот только в нативных приложениях вам такой опции не дают, да и откат на XML-only там тем более не предусмотрен.
Во первых я могу до сих пор писать приложения без xml и работать с нативными компонентами напрямую из кода. Во вторых описание интефейса на xml информации никакой особо не несет.
Отлично, в браузере можно успешно работать без html, используя только DOM API, собственно оставив только JS кусок кода из моего примера и работая через DOM API я получу тот же результат, что и используя декларацию в HTML посредством <template>.
Так вот именно так и работает большинство фреймворков в вебе, которые в итоге вам не нравятся по причине "отключить JS". В нативном приложении применяем тот же аргумент "отключить язык" и получаем в результате такое же не рабочее приложение.
Как бы вам не кажется весьма странным тащить в html документ линковку и компиляцию?
Никто их именно в HTML не тащит это строго рамки JS и весь код на JS.
Xml в приложения пошел для упрощения описания интерфейса. Идеи Delphi живут и здравствуют.
В случае html мы имеем другой путь. Был html который использовался для документов. Потом туда добавили js и это стало путем когда свернули не туда. По этому сейчас и имеем костыль на костыле
Был Delphi, потом в него добавили XML для документов. Ситуация абсолютно зеркальная. А как же привычные форматы документов, презентаций, таблиц, которые к слову тоже архивы, тоже с xml и тоже в которые добавили макросы (язык программирования).
Где-то во всех этих история свернули не туда и очень давно, ещё раньше современного веба и сейчас мы имеем костыль на костыле повсеместно.
Веб (та часть про http/html/js/css) просто поменял вектор, раньше был только про документы, потом про документы с условно макросами (JS), а сейчас в платформу, вот только эта платформа обратно совместима с предыдущими векторами развития. И использование ряда технологий веба не по первоначальному назначению именно связано с обратной совместимостью, естественно можно разработать что-то с нуля и выкинуть старое (то, что близко, но было переосмысленно), но мы тогда потеряем простые документы.
И в целом это хорошо, вот только процесс перехода в платформу ещё продолжается. Как результат можно получить удобное распространение сервиса в виде веб-приложения, у которого версия будет всегда последней на любой операционной системе, вычисления могут быть так же распределены. Но это результат будет зависеть только от разработчиков и их методов реализации на наборе инструментов, которым и будет платформа веба.
Вообщем веб только на пути к правильной платформе та же инициатива по Web Components / Custom Elements существует и реализуется с 2016 года, но уже 5 раз переделывалась и ещё на стадии 30-40%. Были и импорты отдельных html именно как шаблоны, в результате deprecated, сейчас они вновь возраждаются, но уже не в качестве <link rel="import">, а HTML/CSS модулей в JS. import template from './contact-item.html'
И к слову webpack это просто сборщик, условно компилятор только для веба.
С HTML ситуация абсолютно такая же, поверьте. И ваш пример с отключением JS применим и к нативным приложениям с Java/Kotlin/C#/C++, вот только в них опции отключения этих языков не предоставлено как в браузере. По поводу линковки в нативные компоненты в вебе есть такая штука как Custom Elements, работающая именно так же. Ведь эта самая линковка ничто иное как описание, что этот класс реализует этот шаблон не более. И опять таки убрав реализацию шаблона в xml кодом на Java/Kotlin/C#/C++ интерфейс нативного приложения просто перестанет работать.
Проблема надумана, xml тоже документ. Но мы пытаемся сделать из него приложение при помощи Java/Kotlin/C#/C++ на платформах Windows и Android. И почему-то это не идёт в разрез концепции, а в случае пары HTML / JS идёт. По моему суждения подобные вашему странны, ведь нативные приложения строятся так же.
Это даже не унификация, а именно стандартизация. ES Modules это часть спецификации ECMAScript т.е. новые модули это нативная реализация модулей, работающая в идеале одинаково во всех реализация движков и производных ECMAScript.
Ещё одно из отличий ES Modules от Common JS это то, что ES Modules по своей природе асинхронны, а Common JS синхронны.
Дело в том, что сайты, относящиеся к проекту devsite, сейчас плавно переводят на lit-element в замен устаревшего Polymer и не сказать, что этот перевод проходит безболезненно всё-таки Custom Elements ещё далеки от идеала и на данный момент поставлена задача обновления кодовой базы, а не оптимизация.
Ну и не забывайте, что для SSR на Custom Elements приходится прогонять через Headless Google Chrome это тоже знаете ли время до ответа сервера, учитывая очередь на отрисовку.
Я ради интереса сейчас запустил этот же тест несколько раз в результате получил стабильный показатель 95%. А сообщение на которое было обращено внимание явно основано на статистике — ключевое в сообщении: "Согласно данным, собранным за последние 30 дней".
Насчёт претензий по формату картинок отмечу, что видимо с переносом на новый фреймворк они меняют структуру проекта и на данный момент не сервят картинки с googleusercontent, который динамически перекодирует. У них на данный момент даже правила кеширования изображений не настроены.
Нету никакой "реализации инкапсуляции через weakmap", это вообще НЕ инкапсуляция (т.к. переменная не скрыта)
Ну для начала в данном случае WeakMap единственный на один контекст, при этом не видимый для рантайм и юзается исключительно движком в целях реализации синтаксиса (рантайм не имеет прямого доступа к данному WeakMap), если это не "полное" скрытие, то видимо вы сами запутались.
О ваших рассуждений по поводу имеющихся ООП-языков и т.д. и т.п. не забывайте, что ES отличается от них во первых тем, что он мультипарадигменный язык и поддерживает не только ООП, но ещё и обобщённое, функциональное, императивное, аспектно-ориентированное, событийно-ориентированное, прототипное программирование соответственно уже будет иметь своё отличие в реализации.
Далее не забывайте про главное отличие от других ООП языков — прототипное наследование он сильно отличает ES от многих имеющихся ООП-языков и требует своих подходов в реализации.
Потом что же это такое «стандартная» реализация инкапсуляции и какой это стандарт и действует ли он во всех языках без исключений и не изменен ли он со временем?
ES это отдельный язык, у которого свой путь и принимаемые решения зависят на уже принятых ранее. Причём при всём при этом ES сохраняет обратную совместимость, чего не сказать про тот же Python (переход со 2 версии на 3 был довольно долгим и болезненным)
Никаких викмапов и прочей чуши для этого не надо
Уверены? И вы прям знаете точно во что превращает компилятор синтаксис приватных полей? И это прям точно не похоже на те же WeakMap? Вот серьёзно.
Типичный пример героического преодолевания собственноручно созданных трудностей.
Относительно вас могу так же сказать, что вы типичный пример разработчика, который пытается привнести поведение/инструменты привычного вам языка программирования в другой, что не так плохо, однако типичность заключается в отсутствии оценки применимости и возможности появления данных "инструментов" в конкретном языке.
Вы просто проигнорировали все отличия ES от того же C# или C++ и сказали, что должно быть 1 в 1. Более того ваши представления отличаются от действительности и выше вам на это уже казали.
С тем чтобы закрыть нет никаких трудностей
Приведите пример на ES, в котором будет очень легко реализовать закрытую переменную класса (причём переменная не static, а для каждого инстанса своя), но на синтаксисе ES6-ES10 с использованием синтаксического сахара классов. Главное эта переменная не должна быть доступна кому угодно кроме инстанса/инстансов класса.
И не забудьте оценить применимость вашего подхода при большем числе классов, а так же читаемость получившегося кода.
Лично я спокойно уже использую синтаксис приватных полей и методов в ES, мне действительно нужно защитить от прямого доступа из вне какой-нибудь массив. Т.к. я хочу во первых ограничить методы, вносящие правки, у меня есть обязательные сайд эффекты на эти действия. Вот допустим я делаю очередь воспроизведения медиа контента.
Символ # воспринимаю не более чем принятое языком соглашение по именованию приватных полей. Точно так же как бы использовал _ в других языках (в т.ч. в виду ограничений). Какая разница, что за символ главное своё назначение выполняет — в коде сразу видно приватное поле, в рантайме оно так же приватное (в отличии от _ и для меня этого достаточно).
То, что язык жёстко ограничивает выбор данного префикса — не плохо и не хорошо, тот же Go вообще жёстко ограничивает возможное число реализаций задачи, Python тоже приносит свои ограничения и ничего все пользуются.
В конце концов для каждого языка найдётся свой перечень задач, которые он решает хорошо — язык это только инструмент.
Это всё-таки синтаксис Hard Private соответственно задача закрыть доступ из вне всем и именно в рантайме.
Обеспечение обратной совместимости с точки зрения комитета — не сломать имеющийся код изменением синтаксиса.
Обеспечение обратной совместимости с точки зрения разработчиков — действительно закрыть доступ к полям, используемым для внутренней реализации классов и не предназначенных для внешнего использования.
Упрощение реализации синтаксиса в движках в т.ч. в целях избежать ухудшение производительности.
Почему не использовать зарезервированное в ES ключевое слово private, которое уже применено в TypeScript:
Относительно TypeScript ключевое слово private предназначено непосредственно для разработчиков, которые читают и/или пишут конкретный код. Разработчики, которые используют библиотеку в своих проектах с огромной вероятностью не полезут в исходники библиотеки.
Так же это ключевое слово относительно TypeScript не влияет на рантайм т.к. при компиляции просто напросто вырезается. Соответственно как бы вы не именовали переменную она будет доступна окружению в рантайме. Следовательно ни чего не мешает использовать "приватную" по "соглашению" переменную игнорируя "соглашение", что в свою очередь довольно часто встречается в ES сообществе/экосистеме.
Пример такого использования: изменение поведения кода от наличия переменной или случай использования приватного метода, когда публичный метод и приватный метод выполняют на первый взгляд одно и тоже (однако публичный может так же иметь сайд эффекты).
Рассмотрим с точки зрения упрощения реализации синтаксиса и сохранения производительности:
Если бы мы вводили именно зарезервированное ключевое слово private для Hard Private, в реализациях движков пришлось бы любое обращение к любой переменной проверять на тип т.е. является ли данная переменная в данном объекте приватной или же публичной.
Как движки должны воспринимать случай, когда в родительском классе переменная является приватной, а в производном публичной — как воспринимать эту переменную при её использовании в каком скоупе и т.д.
Так же не забываем, что наименование переменной может быть откровенно говоря любого примитивного типа.
Опять таки относительно Hard Private (полного сокрытия) любая переменная объекта может быть получена подбором через синтаксис object[key], что в случае Hard Private не допустимо.
Это всё в свою очередь явно повлияло бы на производительность. Соответственно проще ввести какой-то дополнительный синтаксис, введение типа по примеру Symbol здесь не подходит в виду последнего пункта.
Какой это должен быть синтаксис? Первое, что приходит на ум это какой-то символ префикс т.к. данный подход по соглашению уже много где используют и это де-факто стандарт. Соглашение может отличаться от команды к команде, но ключевое здесь именно наличие какого-либо префикса.
Причём в сравнении с тем же ключевым словом соглашение по префиксу позволяет судить об области видимости переменной не возвращаясь к месту её объявления. Именно для этого данный подход и был придуман и используется совместно с такими ключевыми словами.
И так какой это должен быть символ-префикс, чтобы при этом не нарушить работу имеющегося кода и не забываем нам нужно избежать доступа через object[key]? (в object.field часть после точки заведомо интерпретируется движками как примитив string и эквивалентно object["field"])
И вот тут появляется символ #, который по стандарту dot notation является не верным и считается ошибкой (invalid) т.е. движки не будут считать часть после точки строкой это обеспечение обратной совместимости со стороны комитета. Таким образом object.#field это не object['#field'] и не object['field'] и не object[#field] т.к. #field не примитив. В реализации движков в данном случае заменяется выброс ошибки на обработку специфичного синтаксиса без проверок примитивного типа ключа (наименования переменной) т.к. это не требуется.
Разработчики библиотек могут получить пользу от Hard Private т.к. в случае если они решат изменить внутреннюю реализацию класса, изменив/заменив/убрав переменные внутренней реализации при этом оставив не изменной публичную часть (API), это будит действительно патч или минорное изменение.
Однако сейчас, когда приватные переменные (переменные внутренней реализации) это просто соглашение, которое часто игнорирует и используется в прямую производными библиотеками и кодом, данный патч/минорное обновление может вылиться и выливается в полноценное мажорное с нарушением обратной совместимости.
И всё из-за нарочного публичного использования заведомо не рассчитанных на это переменных.
Таким образом object.#field это во первых полностью скрытая в рантайме приватная переменная + соглашение по именованию, что позволяет судить о природе переменной в любой точке кода, где это используется, а так же должно восприниматься как совершенно отдельная/скрытая область.
К слову в том же TypeScript при компиляции приватных полей могли бы их помещать в WeakMap по принципу того, как babel компилирует синтаксис #field тем самым делая их на самом деле приватными. Однако в данном случае вызвалась бы коллизия с определением видимости переменной (что использовать и в каком месте — прямое обращение к object.field или к WeakMap).
И ещё замечу, что да # считается синтаксисом common comment в разных языка, НО не в ES (Здесь это именно //) так, что относительно данного языка это не нарушение.
Так же добавлю, что проблем с отладкой приватных переменных особо не должно быть т.к. тот же DevTools уже умеет как минимум отображать их и позволять изменить. А относительно методов можно и скостылить — выгрузить в temp переменную и вызвать через apply.
Все методы попадают в прототип т.е. все методы уже определены ещё до инициализации любого инстанса. А вот поля в инстансе устанавливаются именно в момент инициализации и именно в порядке из глубины (от самого первого предка).
Но мой основной вопрос всё равно не про это — почему инстанс класса предка сразу бы не инициализировать со значениями полей, переопределёнными в классе-потомке?
По тому, что во первых в ECMAScript классы это синтаксический сахар, во вторых вложенность не известна и процесс по своей сути итеративный. А методы так же как и функции получают ровно те значения полей и переменных своих областей видимости, которые имеются на момент вызова функции.
Пример ниже по своей сути ведёт себя совершенно так же как и ваш случай с классом.
function greet() {
console.log(`Hello, ${name}!`)
}
function constructorA() {
Object() // В случае с классами на данном месте неявно вызывается конструктор объекта (super()).
name = 'ninja cat' // Установка условного поля `name` в родительском классе.
greet()
}
function constructorB() {
constructorA() // Это место явного вызова super()
name = 'world' // Установка условного поля `name` в дочернем классе.
}
constructorB()
// Hello, ninja cat!
Данный пример показывает именно то, как представляется синтаксический сахар класса в рантайме (но на обычных функциях).
А это упрощенный пример, показывающий, что любая функция/метод использует значение переменной скоупа на момент вызова. Обращаю внимание, что на момент объявления функции greet() в скоупе о переменной name вообще ничего не известно.
function greet() {
console.log(`Hello, ${name}!`)
}
let name = 'ninja cat'
greet()
// Hello, ninja cat!
name = 'world'
greet()
// Hello, world!
Поэтапное создание класса выглядит не совсем так. B.constructor() будет вызван первым.
Совершенно верно, но я указал именно данный порядок, чтобы было яснее, какое значение поля name будет во время вызова метода log(). Если проще я просто обратную цепочку (из вложения) описал.
Правильнее (подробнее) ваш вариант тогда написать так:
class A {
name = 'A'
constructor() {
console.log('A constructor start')
this.log()
console.log('A constructor finish')
}
log() {
console.log(this.name)
}
}
class B extends A {
name = 'B'
constructor() {
console.log('B constructor start')
super()
console.log('B constructor finish')
}
}
new B()
B constructor start
A constructor start
A
A constructor finish
B constructor finish
И я согласен с автором, что это далеко не очевидно, что инициализация name в B происходит после вызова super().
И всё же на это указывает как спецификация ECMAScript, так и рантайм, если вы попробуете любым образом обратиться к любому полю/методу или установить поле наследующего класса до вызова super().
class B extends A {
constructor() {
this.name = 'B'
super()
}
}
new B()
Uncaught ReferenceError: Must call super constructor in derived class before accessing 'this' or returning from derived constructor
at new B (<anonymous>:15:5)
at <anonymous>:20:1
Т.е. следующие три варианта эквивалентны за исключением того, что в первом и втором случаях поле устанавливается по семантике [[define]], а в третьем по семантике [[set]].
// Первый
class B extends A {
name = 'B'
}
// Второй (эквивалент первого с точностью до принципа установки поля)
class B extends A {
constructor() {
super()
Object.defineProperty(this, 'name', { value: 'B' })
}
}
// Третий
class B extends A {
constructor() {
super()
this.name = 'B'
}
}
К тому же, если переписать код и вместо переменной name использовать метод getName тогда работает так, как автор и ожидал:
В данном случае работает как ожидается только ввиду того, что метод эта та же функция и объявляется он в блоке (скоупе) класса. Как и обычная функция в глобальной области она просто всплывёт вверх и уже к вызову в конструкторе имеет необходимую сигнатуру.
К слову в моем описании поэтапной инициализации инстанса метод log() появился уже на этапе присвоения значения полю name.
Т.е. поля и методы класса при объявлении ведут себя как function, var, let, const в любой области видимости.
LEXA_JAправильно указал, что методы попадают в prototype, а поля непосредственно в объект (по сути таким образом и соблюдается стандартный порядок объявления функций и переменных в областях видимости, но с поправкой на специфику классов). Прототип класса уже полностью известен и сформирован на момент создания инстанса.
Опять таки я указал способы достижения ожидаемого результата, используя микротаск — всё, что нам нужно это вызвать условную функцию log() в следующем такте исполнения.
На самом деле поведение очень даже логичное и понятное. Разберу пример:
class A {
name = 'A'
constructor() {
this.log()
}
log() {
console.log(this.name)
}
}
class B extends A {
name = 'B'
}
new B
// A
Почему так происходит?
Всё на самом деле очень просто — в классе A не указан конструктор, соответственно используется конструктор "по умолчанию" т.е. класс выглядит так:
class B extends A {
name = 'B'
constructor() {
super()
}
}
Любой наследующий класс должен в своём конструкторе сначала вызывать конструктор родительского класса (делается это через super()) и только потом производить необходимые манипуляции с инстансом.
Соответственно поле name указанное в классе B будет установлено только после выполнения конструктора класса A.
Поэтапное создание инстанса класса B будет выглядить так:
Т.е. на момент вызова метода log() инстанс класса B содержит в поле name значение A, .
Как добиться ожидаемого в данном примере поведения?
Есть к примеру способ, который указал vvadzim, но он требует переноса инициализации в отдельный метод.
Но есть и более простой способ, не требующий переноса инициализации в отдельный метод.
Что это за способ? Ответ: Вызов метода log() в микротаске, но как? Есть опять таки два равносильных варианта:
// 1 вариант - Микротаск через Promise
class A {
name = 'A'
constructor() {
Promise.resolve().then(() => this.log())
}
log() {
console.log(this.name)
}
}
// 2 вариант - Микротаск по запросу
class A {
name = 'A'
constructor() {
queueMicrotask(() => this.log())
}
log() {
console.log(this.name)
}
}
Команда Polymer Project в проекте lit-element по сути так же использует микротаски (через метод _enqueueUpdate).
Письменное согласие значит именно подпись от руки для возможности проведения почерковедческой экспертизы в случае чего.
Сбербанк ни как не афилирован с Ростелекомом в плане биометрии, более того Сбербанк изначально делает свою отдельную систему, конкурентную Ростелекомовской.
Из-за «babel» это уже не про ECMAScript5. В ES5 по спецификации нет стрелочных функций. А кейс «старая нода и babel» это уже синтаксис ES6+ с трансляцией в синтаксис ES5 посредством babel.
Если вы не видите смысла, не пользуйтесь — всё предельно просто. Найдутся как те кто видит в нём смысл так и те, кто не видит — в любом случае у него будет своя аудитория.
Понимаете, вы тоже склоняете к другому абсурду вот только то, о чём я пытаюсь вам донести является действительностью и применяется не только в интернете, устанавливается в рамках законодательства и часто «ноги растут» не из интернета.
хотя бы галочка
Вот например про галочку — в электронном виде, галочкой служит именно факт использования услуг т.к. предоставить услуги без соглашения нельзя, а вы получили услугу, значит вы дали согласие на её получение.
Т.е. именно использование функционала сервисов и является такой галочкой, предупреждением о которой и является серый текст или он же в варианте с галочкой (которая является только психологическим фактором и только разблокирует кнопку отправки в форме).
Пользователь же нажимает на кнопку формы получения услуги именно добровольно, его ни кто не заставляет.
и без которой его точно так же обслужат
Без которой законодательно пользователя не могут обслужить, ведь обслуживает вас юр. лицо, а как я указывал юр. лицо не имеет права предоставить услугу без оферты и согласия с ней клиента.
Оферта обязательна согласно закону в целях обеспечения гарантий/защиты сторон и защищает не только клиентов/пользователей от юр. лиц, но и юр. лиц от клиентов т.к. в разных ситуациях слабой стороной могут оказаться как клиент так и юр. лицо.
передавать его в рекламные сети
Это может быть явно оговорено в части о ПД и будет звучать примерно так (Видоизменённый отрывок, взят из Согласия на обработку ПД, являющегося частью оферты одной из оффлайновых компаний, название компании изменено):
ООО Прогресс вправе поручить обработку персональных данных третьим лицам.
…
ООО Прогресс имеет право направлять информацию, включая информацию рекламного характера, об услугах ООО Прогресс и/или третьих лиц по всем известным ООО Прогресс адресам и контактам, в том числе посредством телефонной коммуникации/ направления смс сообщений по указанному клиентом номеру мобильного телефона, а также посредством направления сообщений по указанному клиентом адресу электронной почты.
Точно так же и на сервисе в оферте могут быть указаны подобные пункты. И как я уже говорил, если пользователь не согласен с этими пунктами, то юр. лицо не должно предоставить пользователю услуг т.е. пользователь не имеет права воспользоваться услугами.
И вот понимаете в чём дело — то о чём вы так долго пытаетесь донести я прекрасно понимаю, однако так не работает с оффлайновыми компаниями, а значит и не должно с онлайновыми. Ещё в добавок является нечестным по отношению к компании, заведомо выставляя её слабой стороной.
Ведь вы не сможете получить услугу в оффлайне без соглашения в виду действия закона, просто по тому, что вам её не будут предоставлять.
Т.е. в оффлайне есть возможность проконтролировать ваше согласие непосредственно сотрудником и документом с вашей росписью, а вот в онлайне это возможно в основном только постфактум т.е. после отправки пользователем формы (получения услуги), считая пользователя уже согласившимся (в случае если в оферте это указано, а в оферте это будет указано в 1 или во 2 секции, то и суды принимают факт отправки как факт согласия). Своего рода исполнение этого контроля переносится на пользователя и зависит от его добросовестности.
Честный, порядочный магазин так делать не будет и потому ему эта бюрократия работать никак не помешает.
Опять таки это ваша точка зрения, однако я привёл пример честной, порядочной компании из оффлайна (хотя это может измениться в любой момент). И она так делает.
То же самое должно касаться и других ситуаций. Если компания предоставляет бесплатную почту, она не должна сканировать содержимое писем и продавать эту информацию об интересах рекламодателям без явного согласия пользователя.
Как я сказал, читайте оферту, там это указано и в случае с предоставлением почты — ведь почту предоставляют только после процесса регистрации, а процесс регистрации явно указан как акцепт оферты и даже в форме регистрации об этом сказано и дана ссылка на оферту и даже сделан психологический фактор в виде галочки. Следовательно вы сами поставили галочку, прошли процедуру регистрации, тем самым явно дав своё согласие на условия оферты.
Речь именно о том, что данные могут использоваться для других целей. Например, для продажи информации рекламодателям о потенциально обеспеченном пользователе (раз он ездит на такси, а не на велосипеде) или продажи информации о том, где живет или работает пользователь. Такие вещи должны ограничиваться.
В оффлайне всё происходит точно так же, вы может не задумывались.
И любые из этих целей могут быть указаны в Соглашении на обработку ПД как в онлайне, так и в оффлайне и будут законны.
Опять таки вас явно об этом оповещают, но вот вы на это не обращаете внимание. В оффлайне часто не читая подписываете соглашения (часто с отговоркой, что у них одна форма, однако одно из соглашений может иметь дополнительный пункт, с которым вы может не согласитесь), а в онлайне пользуетесь услугами сервисов (что согласно офертам сервисов является согласием с условиями).
Нет. Если вы говорите «либо вы разрешаете продавать ваши данные, либо не ездите на нашем такси»
Вот тут вы явно в абсурд склоняетесь т.к. именно это говорят все компании, предоставляющие услуги как в оффлайне так и в онлайне.
Более того об этом и говорит закон, обязывающий предоставление услуг юр. лицами только по оферте и только после согласия клиента с условиями оферты — «либо вы согласны со всеми условиями предоставления услуги (в том числе как вы постоянно акцентируете „продавать ваши данные“, если это указано в условиях), либо не получаете услугу».
Пользователь хотел Ютубом воспользоваться
Не все ожидания пользователя соответствуют действительности и пользователь должен принимать решение об использовании сервиса не на основе своих ожиданий, которые могут быть ложными, а на фактических условиях (оферте), где явно сказано чем является сервис, что вам даётся, а что вы даёте в замен.
Именно в оферте указаны эти «подводные камни», на которые пользователь может наткнуться, если руководствуется исключительно ожиданиями и тем как должен работать сервис по его личному мнению и восприятию.
К счастью, GDPR предусматривает и явно запрещает отказывать в обслуживании, даже если пользователь не дал согласие продавать свои данные. Не знаю, увы, как с этим в России. Но в Европе ему должны подать такси в любом случае, независимо от того, что написано в оферте.
Какая чушь, т.к. подобное законодательство, регулирующее предоставление услуг имеется у всех государств и формат везде примерно одинаковый т.к. фактически это международные правила ведения бизнеса.
Вот вам пример условий Apple в Германии (т.е. непосредственно на территории ЕС и по законам ЕС):
Оригинал:
Diese Nutzungsbedingungen (die «Nutzungsbedingungen») gelten für die Apple Website unter www.apple.com und alle zugehörigen Websites, die von Apple mit www.apple.com verlinkt sind, sowie Unter- und Partnerseiten, einschließlich aller Apple Websites weltweit (gemeinsam «die Website»). Die Website ist Eigentum von Apple Inc. («Apple») und seinen Lizenzgebern. INDEM SIE DIE WEBSITE VERWENDEN, ERKLÄREN SIE IHR EINVERSTÄNDNIS MIT DIESEN NUTZUNGSBEDINGUNGEN. VERWENDEN SIE DIE WEBSITE NICHT, WENN SIE MIT DIESEN BEDINGUNGEN NICHT EINVERSTANDEN SIND.
Перевод:
Настоящие условия использования («Условия использования») распространяются на веб-сайт Apple по адресу www.apple.com и на все связанные с ним сайты, а также на партнерские сайты, включая все веб-сайты Apple во всем мире (в совокупности «веб-сайт»). Сайт является собственностью Apple Inc. («Apple») и его лицензиаров. ИСПОЛЬЗУЯ САЙТ ВЫ СОГЛАШАЕТЕСЬ СОБЛЮДАТЬ ЭТИ УСЛОВИЯ ИСПОЛЬЗОВАНИЯ. НЕ ИСПОЛЬЗУЙТЕ САЙТ, ЕСЛИ ВЫ НЕ СОГЛАСНЫ С ЭТИМИ УСЛОВИЯМИ.
Это те же пункты об отказе в обслуживании в случае несогласия. Почитайте полностью условия на сайте, многое узнаете. По поводу такси, так же почитайте условия того же Uber. Ещё можете глянуть условия Spotify.
Что касается GDPR, так вот его непосредственным аналогом является именно закон о защите ПД (они основаны на одних и тех же ключевых принципах) т.е. тот самый аналог GDPR, который вы требуете фактически уже имеется и работает.
скорее всего сопоставляются с введенными им при регистрации в Яндексе данными
Опять таки ваша догадка, но это не значит, что она верна. Лучше вместо догадок почитайте условия предоставления Яндекс.Аудиторий, там всё будет сказано и указано т.к. фактически оферта Яндекс.Аудиторий является договором между компаниями условно Магазином, который воспользовался услугами Яндекс.Аудиторий и Яндексом.
Я не знаю, как там это выглядит с юридической стороны, но с человеческой стороны это некрасиво.
Всё регулируется законами, а не предположениями/ощущениями/эмоциями. И если с юридической стороны всё в порядке, то значит всё в порядке.
Вот вам пример Маркетплейсов: Apple Store и Google Play, в одном из них Администрация полностью мониторит качество продуктов и продавцов, что не исключает косяков проверенных продавцов. В другом же случае в том числе и ввиду ограниченных ресурсных возможностей не полностью мониторят всё, что представлено на платформе и частично обязанности перекладывают на продавцов. Соответственно в первом случае полностью проверенный Маркетплейсом, но так же не избавленный от возможных проблем список продуктов и продавцов, но этот список сильно ограничен. В другом же список товаров/продавцов более обширный, но менее проверенный.
Опять таки я именно указал, что Маркетплейс может так делать, во всяком случае сейчас и это ничего не нарушает.
Если вы не готовы брать на себя риски за косяк Продавца, почему их должен брать пользователь, у которого меньше информации (у него в отличие от Маркетплейса нет доступа к истории работы Продавца) и возможностей для борьбы в суде?
Я вам уже указывал, что вы как Пользователь Маркетплейса в случае появления претензий можете попросить содействия со стороны Маркетплейса. Т.е. вы можете запросить у Маркетплейса эту самую информацию о продавце с целью передачи вашей жалобы продавцу о чём вы и оповестите Маркетплейс в просьбе — в случае с иском вы указываете, что запрашиваете информацию с целью подачи иска на Продавца. Маркетплейс предоставит необходимые данные, которыми он обладает, а ещё может встать на вашу сторону в суде, но не обязан.
И ровно так же всё работает относительно прочих площадок, размещения Продавцов.
Ну как не меняете, а как же смена экрана (одной xml на другую) иначе интерфейс был бы статическим и причина не в отзывчивости. Вы всё-равно вызываете какой-то метод на Java/Kotlin/C#/C++, чтобы поставить другую xml на вьюхе. Опять таки всё абсолютно так же.
По поводу поисковых роботов, как бы уже всё-равно они умеют в JS и т.д. с хитростями, но всё же. Например, текущий GoogleBot работает на базе Headless Google Chrome 80 и начиная с прошлого месяца он EverGreen т.е. обновляется синхронно с бразуером. У Яндекса так же +-.
SSR нужен в первую очередь не для роботов, а для людей со слабым интернетом, чтобы они не ждали весь клиентский JS код и когда код отрисует содержимое, а уже могли видеть контент.
А причина переноса всего фронтенда (клиент и сервер) на JS в желании оптимизировать разработку, ведь это удобно, когда один и тот же код работает как на клиенте, так и на сервере. И к этой оптимизации уже с 2015 года некоторые пришли.
Вообще вся эта ветка комментариев это просто "Раньше было лучше" и "В наше время" и применить это можно к чему угодно, хоть к появлению языка Swift или Kotlin. Но время идёт, меняются реалии, цели, задачи.
Ещё раз такая же ситуация.
Отображаться да, работать зависит от ваших нужд, для работы форм у вас всё-равно должен использоваться какой-то язык программирования на стороне сервера. Для только гипертекста этого действительно хватит.
Это зависит от того как вы реализуете свой сайт HTML+JS, если используете прогрессивные методы, то в случае отключения JS просто откатитесь до HTML-only, который как вы чуть раньше указали будет работать без всякого JS. А вот если вы делаете SPA со 100% отрисовкой на клиенте, то да будете показывать табличку.
Опять же если в нативных приложениях дать возможность отключать язык программирования, сохраняя только разметку XML — получите эту же ситуацию, вот только в нативных приложениях вам такой опции не дают, да и откат на XML-only там тем более не предусмотрен.
Отлично, в браузере можно успешно работать без html, используя только DOM API, собственно оставив только JS кусок кода из моего примера и работая через DOM API я получу тот же результат, что и используя декларацию в HTML посредством
<template>
.Так вот именно так и работает большинство фреймворков в вебе, которые в итоге вам не нравятся по причине "отключить JS". В нативном приложении применяем тот же аргумент "отключить язык" и получаем в результате такое же не рабочее приложение.
Никто их именно в HTML не тащит это строго рамки JS и весь код на JS.
Был Delphi, потом в него добавили XML для документов. Ситуация абсолютно зеркальная. А как же привычные форматы документов, презентаций, таблиц, которые к слову тоже архивы, тоже с xml и тоже в которые добавили макросы (язык программирования).
Где-то во всех этих история свернули не туда и очень давно, ещё раньше современного веба и сейчас мы имеем костыль на костыле повсеместно.
Веб (та часть про http/html/js/css) просто поменял вектор, раньше был только про документы, потом про документы с условно макросами (JS), а сейчас в платформу, вот только эта платформа обратно совместима с предыдущими векторами развития. И использование ряда технологий веба не по первоначальному назначению именно связано с обратной совместимостью, естественно можно разработать что-то с нуля и выкинуть старое (то, что близко, но было переосмысленно), но мы тогда потеряем простые документы.
И в целом это хорошо, вот только процесс перехода в платформу ещё продолжается. Как результат можно получить удобное распространение сервиса в виде веб-приложения, у которого версия будет всегда последней на любой операционной системе, вычисления могут быть так же распределены. Но это результат будет зависеть только от разработчиков и их методов реализации на наборе инструментов, которым и будет платформа веба.
Вообщем веб только на пути к правильной платформе та же инициатива по Web Components / Custom Elements существует и реализуется с 2016 года, но уже 5 раз переделывалась и ещё на стадии 30-40%. Были и импорты отдельных html именно как шаблоны, в результате deprecated, сейчас они вновь возраждаются, но уже не в качестве
<link rel="import">
, а HTML/CSS модулей в JS.import template from './contact-item.html'
И к слову webpack это просто сборщик, условно компилятор только для веба.
С HTML ситуация абсолютно такая же, поверьте. И ваш пример с отключением JS применим и к нативным приложениям с Java/Kotlin/C#/C++, вот только в них опции отключения этих языков не предоставлено как в браузере. По поводу линковки в нативные компоненты в вебе есть такая штука как Custom Elements, работающая именно так же. Ведь эта самая линковка ничто иное как описание, что этот класс реализует этот шаблон не более. И опять таки убрав реализацию шаблона в xml кодом на Java/Kotlin/C#/C++ интерфейс нативного приложения просто перестанет работать.
Пример Custom Elements в HTML / JS:
Для декларации содержимого элемента по примеру с декларацией в xml создан тег
<template>
.Проблема надумана, xml тоже документ. Но мы пытаемся сделать из него приложение при помощи Java/Kotlin/C#/C++ на платформах Windows и Android. И почему-то это не идёт в разрез концепции, а в случае пары HTML / JS идёт. По моему суждения подобные вашему странны, ведь нативные приложения строятся так же.
Это даже не унификация, а именно стандартизация. ES Modules это часть спецификации ECMAScript т.е. новые модули это нативная реализация модулей, работающая в идеале одинаково во всех реализация движков и производных ECMAScript.
Ещё одно из отличий ES Modules от Common JS это то, что ES Modules по своей природе асинхронны, а Common JS синхронны.
По тому, что везде используется бортовая развлекательная система от одного и того же производителя. То есть это даже косяк не РЖД, а поставщика.
Дело в том, что сайты, относящиеся к проекту devsite, сейчас плавно переводят на lit-element в замен устаревшего Polymer и не сказать, что этот перевод проходит безболезненно всё-таки Custom Elements ещё далеки от идеала и на данный момент поставлена задача обновления кодовой базы, а не оптимизация.
Ну и не забывайте, что для SSR на Custom Elements приходится прогонять через Headless Google Chrome это тоже знаете ли время до ответа сервера, учитывая очередь на отрисовку.
Я ради интереса сейчас запустил этот же тест несколько раз в результате получил стабильный показатель 95%. А сообщение на которое было обращено внимание явно основано на статистике — ключевое в сообщении: "Согласно данным, собранным за последние 30 дней".
Насчёт претензий по формату картинок отмечу, что видимо с переносом на новый фреймворк они меняют структуру проекта и на данный момент не сервят картинки с googleusercontent, который динамически перекодирует. У них на данный момент даже правила кеширования изображений не настроены.
Совершенно верно, только конкретно про название Hard Private это даже не я, а сам комитет так называет.
Раз уж вы стали цепляться за всё и вся начнём.
Ну для начала в данном случае WeakMap единственный на один контекст, при этом не видимый для рантайм и юзается исключительно движком в целях реализации синтаксиса (рантайм не имеет прямого доступа к данному WeakMap), если это не "полное" скрытие, то видимо вы сами запутались.
О ваших рассуждений по поводу имеющихся ООП-языков и т.д. и т.п. не забывайте, что ES отличается от них во первых тем, что он мультипарадигменный язык и поддерживает не только ООП, но ещё и обобщённое, функциональное, императивное, аспектно-ориентированное, событийно-ориентированное, прототипное программирование соответственно уже будет иметь своё отличие в реализации.
Далее не забывайте про главное отличие от других ООП языков — прототипное наследование он сильно отличает ES от многих имеющихся ООП-языков и требует своих подходов в реализации.
Потом что же это такое «стандартная» реализация инкапсуляции и какой это стандарт и действует ли он во всех языках без исключений и не изменен ли он со временем?
ES это отдельный язык, у которого свой путь и принимаемые решения зависят на уже принятых ранее. Причём при всём при этом ES сохраняет обратную совместимость, чего не сказать про тот же Python (переход со 2 версии на 3 был довольно долгим и болезненным)
Уверены? И вы прям знаете точно во что превращает компилятор синтаксис приватных полей? И это прям точно не похоже на те же WeakMap? Вот серьёзно.
Относительно вас могу так же сказать, что вы типичный пример разработчика, который пытается привнести поведение/инструменты привычного вам языка программирования в другой, что не так плохо, однако типичность заключается в отсутствии оценки применимости и возможности появления данных "инструментов" в конкретном языке.
Вы просто проигнорировали все отличия ES от того же C# или C++ и сказали, что должно быть 1 в 1. Более того ваши представления отличаются от действительности и выше вам на это уже казали.
Приведите пример на ES, в котором будет очень легко реализовать закрытую переменную класса (причём переменная не static, а для каждого инстанса своя), но на синтаксисе ES6-ES10 с использованием синтаксического сахара классов. Главное эта переменная не должна быть доступна кому угодно кроме инстанса/инстансов класса.
И не забудьте оценить применимость вашего подхода при большем числе классов, а так же читаемость получившегося кода.
Лично я спокойно уже использую синтаксис приватных полей и методов в ES, мне действительно нужно защитить от прямого доступа из вне какой-нибудь массив. Т.к. я хочу во первых ограничить методы, вносящие правки, у меня есть обязательные сайд эффекты на эти действия. Вот допустим я делаю очередь воспроизведения медиа контента.
Символ # воспринимаю не более чем принятое языком соглашение по именованию приватных полей. Точно так же как бы использовал
_
в других языках (в т.ч. в виду ограничений). Какая разница, что за символ главное своё назначение выполняет — в коде сразу видно приватное поле, в рантайме оно так же приватное (в отличии от_
и для меня этого достаточно).То, что язык жёстко ограничивает выбор данного префикса — не плохо и не хорошо, тот же Go вообще жёстко ограничивает возможное число реализаций задачи, Python тоже приносит свои ограничения и ничего все пользуются.
В конце концов для каждого языка найдётся свой перечень задач, которые он решает хорошо — язык это только инструмент.
Причин этому синтаксису несколько:
Почему не использовать зарезервированное в ES ключевое слово
private
, которое уже применено в TypeScript:private
предназначено непосредственно для разработчиков, которые читают и/или пишут конкретный код. Разработчики, которые используют библиотеку в своих проектах с огромной вероятностью не полезут в исходники библиотеки.Рассмотрим с точки зрения упрощения реализации синтаксиса и сохранения производительности:
private
для Hard Private, в реализациях движков пришлось бы любое обращение к любой переменной проверять на тип т.е. является ли данная переменная в данном объекте приватной или же публичной.object[key]
, что в случае Hard Private не допустимо.Это всё в свою очередь явно повлияло бы на производительность. Соответственно проще ввести какой-то дополнительный синтаксис, введение типа по примеру Symbol здесь не подходит в виду последнего пункта.
Какой это должен быть синтаксис? Первое, что приходит на ум это какой-то символ префикс т.к. данный подход по соглашению уже много где используют и это де-факто стандарт. Соглашение может отличаться от команды к команде, но ключевое здесь именно наличие какого-либо префикса.
Причём в сравнении с тем же ключевым словом соглашение по префиксу позволяет судить об области видимости переменной не возвращаясь к месту её объявления. Именно для этого данный подход и был придуман и используется совместно с такими ключевыми словами.
И так какой это должен быть символ-префикс, чтобы при этом не нарушить работу имеющегося кода и не забываем нам нужно избежать доступа через
object[key]
? (вobject.field
часть после точки заведомо интерпретируется движками как примитив string и эквивалентноobject["field"]
)И вот тут появляется символ #, который по стандарту dot notation является не верным и считается ошибкой (invalid) т.е. движки не будут считать часть после точки строкой это обеспечение обратной совместимости со стороны комитета. Таким образом
object.#field
это неobject['#field']
и неobject['field']
и неobject[#field]
т.к.#field
не примитив. В реализации движков в данном случае заменяется выброс ошибки на обработку специфичного синтаксиса без проверок примитивного типа ключа (наименования переменной) т.к. это не требуется.Разработчики библиотек могут получить пользу от Hard Private т.к. в случае если они решат изменить внутреннюю реализацию класса, изменив/заменив/убрав переменные внутренней реализации при этом оставив не изменной публичную часть (API), это будит действительно патч или минорное изменение.
Однако сейчас, когда приватные переменные (переменные внутренней реализации) это просто соглашение, которое часто игнорирует и используется в прямую производными библиотеками и кодом, данный патч/минорное обновление может вылиться и выливается в полноценное мажорное с нарушением обратной совместимости.
И всё из-за нарочного публичного использования заведомо не рассчитанных на это переменных.
Таким образом
object.#field
это во первых полностью скрытая в рантайме приватная переменная + соглашение по именованию, что позволяет судить о природе переменной в любой точке кода, где это используется, а так же должно восприниматься как совершенно отдельная/скрытая область.К слову в том же TypeScript при компиляции приватных полей могли бы их помещать в WeakMap по принципу того, как babel компилирует синтаксис
#field
тем самым делая их на самом деле приватными. Однако в данном случае вызвалась бы коллизия с определением видимости переменной (что использовать и в каком месте — прямое обращение к object.field или к WeakMap).И ещё замечу, что да
#
считается синтаксисом common comment в разных языка, НО не в ES (Здесь это именно//
) так, что относительно данного языка это не нарушение.Так же добавлю, что проблем с отладкой приватных переменных особо не должно быть т.к. тот же DevTools уже умеет как минимум отображать их и позволять изменить. А относительно методов можно и скостылить — выгрузить в temp переменную и вызвать через apply.
Все методы попадают в прототип т.е. все методы уже определены ещё до инициализации любого инстанса. А вот поля в инстансе устанавливаются именно в момент инициализации и именно в порядке из глубины (от самого первого предка).
По тому, что во первых в ECMAScript классы это синтаксический сахар, во вторых вложенность не известна и процесс по своей сути итеративный. А методы так же как и функции получают ровно те значения полей и переменных своих областей видимости, которые имеются на момент вызова функции.
Пример ниже по своей сути ведёт себя совершенно так же как и ваш случай с классом.
Данный пример показывает именно то, как представляется синтаксический сахар класса в рантайме (но на обычных функциях).
А это упрощенный пример, показывающий, что любая функция/метод использует значение переменной скоупа на момент вызова. Обращаю внимание, что на момент объявления функции greet() в скоупе о переменной name вообще ничего не известно.
Совершенно верно, но я указал именно данный порядок, чтобы было яснее, какое значение поля
name
будет во время вызова методаlog()
. Если проще я просто обратную цепочку (из вложения) описал.Правильнее (подробнее) ваш вариант тогда написать так:
И всё же на это указывает как спецификация ECMAScript, так и рантайм, если вы попробуете любым образом обратиться к любому полю/методу или установить поле наследующего класса до вызова
super()
.Т.е. следующие три варианта эквивалентны за исключением того, что в первом и втором случаях поле устанавливается по семантике [[define]], а в третьем по семантике [[set]].
В данном случае работает как ожидается только ввиду того, что метод эта та же функция и объявляется он в блоке (скоупе) класса. Как и обычная функция в глобальной области она просто всплывёт вверх и уже к вызову в конструкторе имеет необходимую сигнатуру.
К слову в моем описании поэтапной инициализации инстанса метод log() появился уже на этапе присвоения значения полю
name
.Т.е. поля и методы класса при объявлении ведут себя как function, var, let, const в любой области видимости.
LEXA_JA правильно указал, что методы попадают в prototype, а поля непосредственно в объект (по сути таким образом и соблюдается стандартный порядок объявления функций и переменных в областях видимости, но с поправкой на специфику классов). Прототип класса уже полностью известен и сформирован на момент создания инстанса.
И ответ на ваш комментарий в соседней ветке: https://github.com/tc39/proposal-class-fields.
Опять таки я указал способы достижения ожидаемого результата, используя микротаск — всё, что нам нужно это вызвать условную функцию
log()
в следующем такте исполнения.На самом деле поведение очень даже логичное и понятное. Разберу пример:
Почему так происходит?
Всё на самом деле очень просто — в классе
A
не указан конструктор, соответственно используется конструктор "по умолчанию" т.е. класс выглядит так:Любой наследующий класс должен в своём конструкторе сначала вызывать конструктор родительского класса (делается это через
super()
) и только потом производить необходимые манипуляции с инстансом.Соответственно поле
name
указанное в классеB
будет установлено только после выполнения конструктора классаA
.Поэтапное создание инстанса класса
B
будет выглядить так:Т.е. на момент вызова метода
log()
инстанс классаB
содержит в полеname
значениеA
, .Как добиться ожидаемого в данном примере поведения?
Что это за способ? Ответ: Вызов метода
log()
в микротаске, но как? Есть опять таки два равносильных варианта:Команда Polymer Project в проекте lit-element по сути так же использует микротаски (через метод _enqueueUpdate).
Письменное согласие значит именно подпись от руки для возможности проведения почерковедческой экспертизы в случае чего.
Сбербанк ни как не афилирован с Ростелекомом в плане биометрии, более того Сбербанк изначально делает свою отдельную систему, конкурентную Ростелекомовской.
И нет Оператор БС не только Ростелекомом.
Из-за «babel» это уже не про ECMAScript5. В ES5 по спецификации нет стрелочных функций. А кейс «старая нода и babel» это уже синтаксис ES6+ с трансляцией в синтаксис ES5 посредством babel.
Ну такие сети уже давно имеются
Если вы не видите смысла, не пользуйтесь — всё предельно просто. Найдутся как те кто видит в нём смысл так и те, кто не видит — в любом случае у него будет своя аудитория.
Вот например про галочку — в электронном виде, галочкой служит именно факт использования услуг т.к. предоставить услуги без соглашения нельзя, а вы получили услугу, значит вы дали согласие на её получение.
Т.е. именно использование функционала сервисов и является такой галочкой, предупреждением о которой и является серый текст или он же в варианте с галочкой (которая является только психологическим фактором и только разблокирует кнопку отправки в форме).
Пользователь же нажимает на кнопку формы получения услуги именно добровольно, его ни кто не заставляет.
Без которой законодательно пользователя не могут обслужить, ведь обслуживает вас юр. лицо, а как я указывал юр. лицо не имеет права предоставить услугу без оферты и согласия с ней клиента.
Оферта обязательна согласно закону в целях обеспечения гарантий/защиты сторон и защищает не только клиентов/пользователей от юр. лиц, но и юр. лиц от клиентов т.к. в разных ситуациях слабой стороной могут оказаться как клиент так и юр. лицо.
Это может быть явно оговорено в части о ПД и будет звучать примерно так (Видоизменённый отрывок, взят из Согласия на обработку ПД, являющегося частью оферты одной из оффлайновых компаний, название компании изменено):
Точно так же и на сервисе в оферте могут быть указаны подобные пункты. И как я уже говорил, если пользователь не согласен с этими пунктами, то юр. лицо не должно предоставить пользователю услуг т.е. пользователь не имеет права воспользоваться услугами.
И вот понимаете в чём дело — то о чём вы так долго пытаетесь донести я прекрасно понимаю, однако так не работает с оффлайновыми компаниями, а значит и не должно с онлайновыми. Ещё в добавок является нечестным по отношению к компании, заведомо выставляя её слабой стороной.
Ведь вы не сможете получить услугу в оффлайне без соглашения в виду действия закона, просто по тому, что вам её не будут предоставлять.
Т.е. в оффлайне есть возможность проконтролировать ваше согласие непосредственно сотрудником и документом с вашей росписью, а вот в онлайне это возможно в основном только постфактум т.е. после отправки пользователем формы (получения услуги), считая пользователя уже согласившимся (в случае если в оферте это указано, а в оферте это будет указано в 1 или во 2 секции, то и суды принимают факт отправки как факт согласия). Своего рода исполнение этого контроля переносится на пользователя и зависит от его добросовестности.
Опять таки это ваша точка зрения, однако я привёл пример честной, порядочной компании из оффлайна (хотя это может измениться в любой момент). И она так делает.
Как я сказал, читайте оферту, там это указано и в случае с предоставлением почты — ведь почту предоставляют только после процесса регистрации, а процесс регистрации явно указан как акцепт оферты и даже в форме регистрации об этом сказано и дана ссылка на оферту и даже сделан психологический фактор в виде галочки. Следовательно вы сами поставили галочку, прошли процедуру регистрации, тем самым явно дав своё согласие на условия оферты.
В оффлайне всё происходит точно так же, вы может не задумывались.
Обработкой ПД законодательно считаются: сбор, запись, систематизация, накопление, хранение, уточнение, использование, передача третьим лицам, обезличивание, блокирование, удаление, уничтожение.
И любые из этих целей могут быть указаны в Соглашении на обработку ПД как в онлайне, так и в оффлайне и будут законны.
Опять таки вас явно об этом оповещают, но вот вы на это не обращаете внимание. В оффлайне часто не читая подписываете соглашения (часто с отговоркой, что у них одна форма, однако одно из соглашений может иметь дополнительный пункт, с которым вы может не согласитесь), а в онлайне пользуетесь услугами сервисов (что согласно офертам сервисов является согласием с условиями).
Вот тут вы явно в абсурд склоняетесь т.к. именно это говорят все компании, предоставляющие услуги как в оффлайне так и в онлайне.
Более того об этом и говорит закон, обязывающий предоставление услуг юр. лицами только по оферте и только после согласия клиента с условиями оферты — «либо вы согласны со всеми условиями предоставления услуги (в том числе как вы постоянно акцентируете „продавать ваши данные“, если это указано в условиях), либо не получаете услугу».
Не все ожидания пользователя соответствуют действительности и пользователь должен принимать решение об использовании сервиса не на основе своих ожиданий, которые могут быть ложными, а на фактических условиях (оферте), где явно сказано чем является сервис, что вам даётся, а что вы даёте в замен.
Именно в оферте указаны эти «подводные камни», на которые пользователь может наткнуться, если руководствуется исключительно ожиданиями и тем как должен работать сервис по его личному мнению и восприятию.
Какая чушь, т.к. подобное законодательство, регулирующее предоставление услуг имеется у всех государств и формат везде примерно одинаковый т.к. фактически это международные правила ведения бизнеса.
Вот вам пример условий Apple в Германии (т.е. непосредственно на территории ЕС и по законам ЕС):
Это те же пункты об отказе в обслуживании в случае несогласия. Почитайте полностью условия на сайте, многое узнаете. По поводу такси, так же почитайте условия того же Uber. Ещё можете глянуть условия Spotify.
Что касается GDPR, так вот его непосредственным аналогом является именно закон о защите ПД (они основаны на одних и тех же ключевых принципах) т.е. тот самый аналог GDPR, который вы требуете фактически уже имеется и работает.
Опять таки ваша догадка, но это не значит, что она верна. Лучше вместо догадок почитайте условия предоставления Яндекс.Аудиторий, там всё будет сказано и указано т.к. фактически оферта Яндекс.Аудиторий является договором между компаниями условно Магазином, который воспользовался услугами Яндекс.Аудиторий и Яндексом.
Всё регулируется законами, а не предположениями/ощущениями/эмоциями. И если с юридической стороны всё в порядке, то значит всё в порядке.
Опять таки я именно указал, что Маркетплейс может так делать, во всяком случае сейчас и это ничего не нарушает.
Я вам уже указывал, что вы как Пользователь Маркетплейса в случае появления претензий можете попросить содействия со стороны Маркетплейса. Т.е. вы можете запросить у Маркетплейса эту самую информацию о продавце с целью передачи вашей жалобы продавцу о чём вы и оповестите Маркетплейс в просьбе — в случае с иском вы указываете, что запрашиваете информацию с целью подачи иска на Продавца. Маркетплейс предоставит необходимые данные, которыми он обладает, а ещё может встать на вашу сторону в суде, но не обязан.
И ровно так же всё работает относительно прочих площадок, размещения Продавцов.