История изменений
Исправление LINUX-ORG-RU, (текущая версия) :
Ну, сомневаюсь что моё мнение тут будет полезно и что-то значит, но уж раз спросил, во первых как по мне плюсовый вариант ::
не надо, слишком жирное написание, а foo::bar::baz::camaz
выглядит вообще ужасно.
А вот двоеточие как возможность косвенного обращения к самому себе имеет смысл. Но это скорее относится к структурам данных, чем к сахару позволяющему не указывать первый аргумент в функции.
Удобство в том что когда например возвращаем файл, можно возвращать не примитив вроде просто числа как дескриптора, а структуру (указатель на неё), с полями которые обрабатывают эту же структуру данных.
Ещё удобство в том что в неком роде это решает проблемы именований, если есть несколько типов данных которым мы хотим задать значение то
type_foo:set("lala")
type_bar:set(42)
иногда, лучше чем
type_foo_set(type_foo,"lala")
type_bar_set(type_bar,42)
Так set
являясь полем может быть легко переопределена, динамически например.
Банальная ситуация, есть у тебя файл и например сетевой сокет, оба могут быть буферизированы и обоим нужно иногда сделать принудительный сброс данных дальше на обработку, семантически это одно и тоже flush
и выбора тут два. Первый, представлять всё как файл, строить высокую абстракцию и передавать
flush(file)
flush(socket)
А различать что есть что уже внутри flush
, а на уровне кода различать именованием. Или делать просто отдельные именованные вызовы для типа данных
file_flush(file)
socket_flush(socket)
В этом нет проблемы, но чисто технически более гибко будет возвращать конкретный тип данных, с готовыми полями в виде функций
file = newfile()
file:write("lala")
file:flush()
socket = newsocket()
socket:send("lala")
socket:flush()
Тут важнее ещё то что можно будет сделать так
if(getos() == "linux")
{
file.flush = linux_flush;
}
например, в иных вариантах нужен будет либо препроцессор, либо
if(getos() == "linux")
{
file_flush = linux_flush;
}
А тут чревато уже может быть.
Я за стиль №2, там визуально видно, чего куда, если уж делать, тут явное разделение обращение к полю как к полю и как только к вызову с неявным аргументом, нужно и то и то порой.
Иными словами, как по мне нет проблем в записи strbuf_append_cstr4
и buf:append_cstr4
в целом разницы то никакой, разница она появляется как следствие, в динамике написания кода. Ну и первый вариант быстрее, даже на просто уровне обработки до компиляции, так что если и привносить косвенный первый аргумент в функции, то оставить и возможность первого варианта, обычного вызова, обычной функции с обычными аргументами, напрмимер в той же Lua
дохренища вариантов сделать и так и сяк и эдак, но я часто пишу на Lua как на Си, ну просто такой подход тупо быстрее работает. Например
m3 = matrix_pow(m1,m2)
вместо
m1:pow(m2)
Даже несмотря на краткость записи, в случае обработки этого в цикле удобнее первый вариант.
Но никто не помешает сделать так
m3 = m1.pow(m1,m2)
Но в любом случае это палка о двух концах
- а если у нас есть args/argc то какое количество аргументов мы будем сообщать с учётом неявного аргумента или без его
- нужно ключевое слово обращения к неявному аргументу
- как обрабатывать ситуации если через
:
делается вызов функции у которой единственный аргумент и он не является структурой данных/типом данных который передаётся неявно. - можно ли через
:
вызывать функцию которая не является полем, а просто левой функцией
foo(x)
{
print(x+x)
}
bar = {"hello"}
bar:foo() ????????? \o_0/ ! ! \0_O\
И так далее. Как по мне, прежде чем реализовать, нужно пройтись по всем «последствиям» и теоретическим констуркциям которые вдруг будут записаны программистом, так как чисто синтаксически они вполне себе могут быть :D
В динамическом языке проблем нет, там слой абстракции позволяет дичь делать в динамике. А у тебя вот не знаю. Может как в случае с сишным for
сахарок будет, делает что-то конкретное, конкретно сахар для неявного аргумента, только для заранее определённых полей данных в виде функций. И всё, на места разворачивать неявный аргумент в явный и всё, как вариант вызова и не более того. Не как замена, а как дополнение к классическим вызовам процедур.
Типа такого. Мысли в слух.
Исходная версия LINUX-ORG-RU, :
Ну, сомневаюсь что моё мнение тут будет полезно и что-то значит, но уж раз спросил, во первых как по мне плюсовый вариант ::
не надо, слишком жирное написание, а foo::bar::baz::camaz
выглядит вообще ужасно.
А вот двоеточие как возможность косвенного обращения к самому себе имеет смысл. Но это скорее относится к структурам данных, чем к сахару позволяющему не указывать первый аргумент в функции.
Удобство в том что когда например возвращаем файл, можно возвращать не примитив вроде просто числа как дескриптора, а структуру (указатель на неё), с полями которые обрабатывают эту же структуру данных.
Ещё удобство в том что в неком роде это решает проблемы именований, если есть несколько типов данных которым мы хотим задать значение то
type_foo:set("lala")
type_bar:set(42)
иногда, лучше чем
type_foo_set(type_foo,"lala")
type_bar_set(type_bar,42)
Так set
являясь полем может быть легко переопределена, динамически например.
Банальная ситуация, есть у тебя файл и например сетевой сокет, оба могут быть буферизированы и обоим нужно иногда сделать принудительный сброс данных дальше на обработку, семантически это одно и тоже flush
и выбора тут два. Первый, представлять всё как файл, строить высокую абстракцию и передавать
flush(file)
flush(socket)
А различать что есть что уже внутри flush
, а на уровне кода различать именованием. Или делать просто отдельные именованные вызовы для типа данных
file_flush(file)
socket_flush(socket)
В этом нет проблемы, но чисто технически более гибко будет возвращать конкретный тип данных, с готовыми полями в виде функций
file = newfile()
file:write("lala")
file:flush()
socket = newsocket()
socket:send("lala")
socket:flush()
Тут важнее ещё то что можно будет сделать так
if(getos() == "linux")
{
file.flush = linux_flush;
}
например, в иных вариантах нужен будет либо препроцессор, либо
if(getos() == "linux")
{
file_flush = linux_flush;
}
А тут чревато уже может быть.
Я за стиль №2, там визуально видно, чего куда, если уж делать, тут явное разделение обращение к полю как к полю и как только к вызову с неявным аргументом, нужно и то и то порой.
Иными словами, как по мне нет проблем в записи strbuf_append_cstr4
и buf:append_cstr4
в целом разницы то никакой, разница она появляется как следствие, в динамике написания кода. Ну и первый вариант быстрее, даже на просто уровне обработки до компиляции, так что если и привносить косвенный первый аргумент в функции, то оставить и возможность первого варианта, обычного вызова, обычной функции с обычными аргументами, напрмимер в той же Lua
дохренища вариантов сделать и так и сяк и эдак, но я часто пишу на Lua как на Си, ну просто такой подход тупо быстрее работает. Например
m3 = matrix_pow(m1,m2)
вместо
m1:pow(m2)
Даже несмотря на краткость записи, в случае обработки этого в цикле удобнее первый вариант.
Но никто не помешает сделать так
m3 = m1.pow(m1,m2)
Но в любом случае это палка о двух концах
- а если у нас есть args/argc то какое количество аргументов мы будем сообщать с учётом неявного аргумента или без его
- нужно ключевое слово обращения к неявному аргументу
- как обрабатывать ситуации если через
:
делается вызов функции у которой единственный аргумент и он не является структурой данных/типом данных который передаётся неявно. - можно ли через
:
вызывать функцию которая не является полем, а просто левой функцией
foo(x)
{
print(x+x)
}
bar = {"hello"}
bar:foo() ????????? \o_0/ ! ! \0_O\
И так далее. Как по мне, прежде чем реализовать, нужно пройтись по всем «последствиям» и теоретическим констуркциям которые вдруг будут записаны программистом, так как чисто синтаксически они вполне себе могут быть :D
В динамическом языке проблем нет, там слой абстракции позволяет дичь делать в динамике. А у тебя вот не знаю. Может как в случае с сишным for
сахарок будет, делает что-то конкретное, конкретно сахар для неявного аргумента, только для заранее определённых полей данных в виде функций. И всё. Не как замена, а как дополнение к классическим вызовам процедур.
Типа такого. Мысли в слух.