Сообщение Re: Никогда не недооценивайте силу по умолчанию от 12.09.2022 10:46
Изменено 12.09.2022 19:49 netch80
Re: Никогда не недооценивайте силу по умолчанию
Здравствуйте, Caracrist, Вы писали:
C>Допустим, вы создавали / выбирали бы сегодня новый язык програмирования. В этом языке есть переменные, структуры данных и функции.
C>Все как у всех.
C>Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?
C>Константность:
C>
В идеале — вообще просто разные слова (let/var, например). Вот для чего-то вроде параметров функций — или те же слова, или таки mutable.
C>Асинхронность:
C>
Крайне сложно выбрать, зависит от домена.
C>Виртуальность:
C>
Direct. Ибо произвольное перекрытие сверху... ну может для тестовых сборок (с отдельным режимом компиляции), но не для всех. Тут лучше какой-то "перекрывать разрешается только таким-то наследникам" (или с конкретными грейдерами).
C>Передача:
C>
Учитывая, что в языках типа Java/C#/Python/etc. реально происходит передача _ссылки_ _по значению_, или вопрос некорректный, или надо его расширить. Чистое по значению это, простите, старый Фортран, где сказав call foo(5) можно было получить, что 5 в памяти стало 6 для всех участников, потому что область константы была модифицирована
А вот для объектов, если не введена явная политика тотальной иммутабельности, передача ссылки по значению это таки нормальный вариант.
C>Видимость:
C>
Умолчание — только private. Легче потом отдельные элементы "расшарить", чем бороться с тем, что тебя поюзали и без согласования с 20 соседними департаментами ты это не ограничишь.
C>Из моего опыта по умолчанию должно быть примерно так:
C>
C>Константность: всё константно, если надо иначе пиши mutable (конверт из константной ссылки с copy-on-write)
C>Асинхронность: всё асинхронно, хочешь синхронный вызов добавь sync
C>Виртуальность: всё виртуально, хочешь прямой вызов объяви снаружи/статический
C>Передача: всё по ссылке, для копии нужно указать value на типе или на переменной.
C>Видимость: всё публичное, если надо спрятать добавляешь private и ко.
C>
Опыт сильно напоминает улучшенный JS. Это всё-таки перекос в одну конкретную сторону.
C>
Тот, что подходит под твой домен задач.
Вообще подобный опросник в варианте скрестили ужа с ежом, то есть C с JS и накрыли хаскелем, мягко говоря, смущает
C>Допустим, вы создавали / выбирали бы сегодня новый язык програмирования. В этом языке есть переменные, структуры данных и функции.
C>Все как у всех.
C>Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?
C>Константность:
C>
C>const / mutable
C>
В идеале — вообще просто разные слова (let/var, например). Вот для чего-то вроде параметров функций — или те же слова, или таки mutable.
C>Асинхронность:
C>
C>sync / async
C>
Крайне сложно выбрать, зависит от домена.
C>Виртуальность:
C>
C>virtual / direct
C>
Direct. Ибо произвольное перекрытие сверху... ну может для тестовых сборок (с отдельным режимом компиляции), но не для всех. Тут лучше какой-то "перекрывать разрешается только таким-то наследникам" (или с конкретными грейдерами).
C>Передача:
C>
C>ref / value
C>
Учитывая, что в языках типа Java/C#/Python/etc. реально происходит передача _ссылки_ _по значению_, или вопрос некорректный, или надо его расширить. Чистое по значению это, простите, старый Фортран, где сказав call foo(5) можно было получить, что 5 в памяти стало 6 для всех участников, потому что область константы была модифицирована
А вот для объектов, если не введена явная политика тотальной иммутабельности, передача ссылки по значению это таки нормальный вариант.
C>Видимость:
C>
C>public / private / ...
C>
Умолчание — только private. Легче потом отдельные элементы "расшарить", чем бороться с тем, что тебя поюзали и без согласования с 20 соседними департаментами ты это не ограничишь.
C>Из моего опыта по умолчанию должно быть примерно так:
C>
C>Константность: всё константно, если надо иначе пиши mutable (конверт из константной ссылки с copy-on-write)
C>Асинхронность: всё асинхронно, хочешь синхронный вызов добавь sync
C>Виртуальность: всё виртуально, хочешь прямой вызов объяви снаружи/статический
C>Передача: всё по ссылке, для копии нужно указать value на типе или на переменной.
C>Видимость: всё публичное, если надо спрятать добавляешь private и ко.
C>
Опыт сильно напоминает улучшенный JS. Это всё-таки перекос в одну конкретную сторону.
C>
Какой язык мне посоветуете?
C>Тот, что подходит под твой домен задач.
Вообще подобный опросник в варианте скрестили ужа с ежом, то есть C с JS и накрыли хаскелем, мягко говоря, смущает
Re: Никогда не недооценивайте силу по умолчанию
Здравствуйте, Caracrist, Вы писали:
C>Допустим, вы создавали / выбирали бы сегодня новый язык програмирования. В этом языке есть переменные, структуры данных и функции.
C>Все как у всех.
C>Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?
C>Константность:
C>
В идеале — вообще просто разные слова (let/var, например). Вот для чего-то вроде параметров функций — или те же слова, или таки mutable.
C>Асинхронность:
C>
Крайне сложно выбрать, зависит от домена.
C>Виртуальность:
C>
Direct. Ибо произвольное перекрытие сверху... ну может для тестовых сборок (с отдельным режимом компиляции), но не для всех. Тут лучше какой-то "перекрывать разрешается только таким-то наследникам" (или с конкретными грейдерами).
C>Передача:
C>
Учитывая, что в языках типа Java/C#/Python/etc. реально происходит передача _ссылки_ _по значению_, или вопрос некорректный, или надо его расширить. Чистое по значению это, простите, старый Фортран, где сказав call foo(5) можно было получить, что 5 в памяти стало 6 для всех участников, потому что область константы была модифицирована
А вот для объектов, если не введена явная политика тотальной иммутабельности, передача ссылки по значению это таки нормальный вариант.
C>Видимость:
C>
Умолчание — [обновлено] лучше всего package-internal (если есть пакеты), за ним по полезности private. Только так. Легче потом отдельные элементы "расшарить", чем бороться с тем, что тебя поюзали и без согласования с 20 соседними департаментами ты это не ограничишь.
C>Из моего опыта по умолчанию должно быть примерно так:
C>
C>Константность: всё константно, если надо иначе пиши mutable (конверт из константной ссылки с copy-on-write)
C>Асинхронность: всё асинхронно, хочешь синхронный вызов добавь sync
C>Виртуальность: всё виртуально, хочешь прямой вызов объяви снаружи/статический
C>Передача: всё по ссылке, для копии нужно указать value на типе или на переменной.
C>Видимость: всё публичное, если надо спрятать добавляешь private и ко.
C>
Опыт сильно напоминает улучшенный JS. Это всё-таки перекос в одну конкретную сторону.
C>
Тот, что подходит под твой домен задач.
Вообще подобный опросник в варианте скрестили ужа с ежом, то есть C с JS и накрыли хаскелем, мягко говоря, смущает
C>Допустим, вы создавали / выбирали бы сегодня новый язык програмирования. В этом языке есть переменные, структуры данных и функции.
C>Все как у всех.
C>Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?
C>Константность:
C>
C>const / mutable
C>
В идеале — вообще просто разные слова (let/var, например). Вот для чего-то вроде параметров функций — или те же слова, или таки mutable.
C>Асинхронность:
C>
C>sync / async
C>
Крайне сложно выбрать, зависит от домена.
C>Виртуальность:
C>
C>virtual / direct
C>
Direct. Ибо произвольное перекрытие сверху... ну может для тестовых сборок (с отдельным режимом компиляции), но не для всех. Тут лучше какой-то "перекрывать разрешается только таким-то наследникам" (или с конкретными грейдерами).
C>Передача:
C>
C>ref / value
C>
Учитывая, что в языках типа Java/C#/Python/etc. реально происходит передача _ссылки_ _по значению_, или вопрос некорректный, или надо его расширить. Чистое по значению это, простите, старый Фортран, где сказав call foo(5) можно было получить, что 5 в памяти стало 6 для всех участников, потому что область константы была модифицирована
А вот для объектов, если не введена явная политика тотальной иммутабельности, передача ссылки по значению это таки нормальный вариант.
C>Видимость:
C>
C>public / private / ...
C>
Умолчание — [обновлено] лучше всего package-internal (если есть пакеты), за ним по полезности private. Только так. Легче потом отдельные элементы "расшарить", чем бороться с тем, что тебя поюзали и без согласования с 20 соседними департаментами ты это не ограничишь.
C>Из моего опыта по умолчанию должно быть примерно так:
C>
C>Константность: всё константно, если надо иначе пиши mutable (конверт из константной ссылки с copy-on-write)
C>Асинхронность: всё асинхронно, хочешь синхронный вызов добавь sync
C>Виртуальность: всё виртуально, хочешь прямой вызов объяви снаружи/статический
C>Передача: всё по ссылке, для копии нужно указать value на типе или на переменной.
C>Видимость: всё публичное, если надо спрятать добавляешь private и ко.
C>
Опыт сильно напоминает улучшенный JS. Это всё-таки перекос в одну конкретную сторону.
C>
Какой язык мне посоветуете?
C>Тот, что подходит под твой домен задач.
Вообще подобный опросник в варианте скрестили ужа с ежом, то есть C с JS и накрыли хаскелем, мягко говоря, смущает