G>>Ну это уже не туплы, а записи (records). Сейчас анонимные типы выполняют аналогичную функциональность, но их нельзя возврашать из методов класса.
G>>Но тут возникают проблемы G>>1)Насколько записи и одинаковыми типами и разными именами полей соместимы нежду собой? G>>2)То же что выше, но когда типы в разных сборках? G>>3)Насколько такие типы будут совмсетимы с обычными туплами?
U>Tuple<string FirstName, string LastName> в любом месте и в любой сборке должен являться одним и тем же типом. С неименнованными туплами не должен иметь ничего общего.
И как это будет работать в существующей системе типов C# и CLR?
G>>ЗЫ. Как уже отмечали выше тупы применять в публичном контракте не стоит без крайней необходимости. U>Сегодняшние туплы, конечно, нельзя ни в коем случае. Именованные туплы было бы можно.
То что ты описываешь — есть анонимные объекты в C#. Есть объекивные причины по которым их нельзя возвращать из методов класса.
Здравствуйте, Undying, Вы писали:
U>Это все равно костыль. При написании этой строчки нужно знать, что функция возвращает именно firstName и lastName и именно в таком порядке.
Ситуация, абсолютно идентичная параметрам метода. Как любит говорить Эрик Мейерс — налицо дуализм, и это очень хорошо. Кортеж — дуальный комплимент параметров метода, более качественная замена уродливым out параметрам. Вот для явного отражения сего факта и нужен совпадающий синтаксис. В шарпе и VB, увы, позиционное использование кортежа невозможно, а явное обращение к First, Second (или что там в tuple) превращает код в малочитаемое гамно.
U> При использовании честных объектов этого знать не нужно.
Никто не мешает тебе использовать объекты. Кортежи на уровень ниже, и то, что есть такой класс Tuple это деталь реализации.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
G>Ну это уже не туплы, а записи (records). Сейчас анонимные типы выполняют аналогичную функциональность
Функциональность у анонимных типов все же не совсем аналогичная. Скорее они решают сходные задачи.
G>Но тут возникают проблемы G>1)Насколько записи и одинаковыми типами и разными именами полей соместимы нежду собой?
Очевидно, совсем несовместимы
G>2)То же что выше, но когда типы в разных сборках?
Должны быть совместимы, но требуется модификация JIT
G>3)Насколько такие типы будут совмсетимы с обычными туплами?
Очевидно, совсем несовместимы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
U>>Tuple<string FirstName, string LastName> в любом месте и в любой сборке должен являться одним и тем же типом. С неименнованными туплами не должен иметь ничего общего. G>И как это будет работать в существующей системе типов C# и CLR?
А при чем здесь существующая система типов C#? Речь о том каким должно быть хорошее решение. Если ограничения C# и CLR не позволяют хорошее решение реализовать даже в будущих версиях, то это плохо, но это совсем другой вопрос.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ситуация, абсолютно идентичная параметрам метода. Как любит говорить Эрик Мейерс — налицо дуализм, и это очень хорошо. Кортеж — дуальный комплимент параметров метода, более качественная замена уродливым out параметрам. Вот для явного отражения сего факта и нужен совпадающий синтаксис. В шарпе и VB, увы, позиционное использование кортежа невозможно, а явное обращение к First, Second (или что там в tuple) превращает код в малочитаемое гамно.
Не понял почему кортеж нужно ограниченно понимать только как замену out параметрам?
class Name
{
string FirstName;
string LastName;
}
inteface ITest
{
Name Name { get; }
}
Первый случай как бы не более понятен (как, к примеру, Func<T, T, int> на практике оказывается понятнее Comparison<T>) и при этом кода требует в разы меньше.
AVK>Никто не мешает тебе использовать объекты. Кортежи на уровень ниже, и то, что есть такой класс Tuple это деталь реализации.
Вообще бы я вопрос шире поставил. Мне бы хотелось не только именованные туплы видеть, но и возможность задания шаблона не только для типа, но и для названий свойств/методов. Т.е. чтобы можно было писать не только KeyValuePair<int, string>, но и KeyValuePair<int, string, Key as Id, Value as Text>.
Здравствуйте, IDL, Вы писали:
IDL>Что-то мне не очень нравиться привязывать имена функции к количеству и порядку елементов в кортеже.
А к возвращаемому значению нравится?
В общем, на мой взгляд эта проблема надумана. Может, конечно, определённые неудобства и есть, но по сравнению с полным отсутствием кортежей эти неудобства не видны в микроскоп.
Если нам не помогут, то мы тоже никого не пощадим.
U>class Name
U>{
U> string FirstName;
U> string LastName;
U>}
U>inteface ITest
U>{
U> Name Name { get; }
U>}
U>
U>Первый случай как бы не более понятен
По какой причине? Мне так второй более понятен, особенно при использовании.
U> (как, к примеру, Func<T, T, int> на практике оказывается понятнее Comparison<T>) и при этом кода требует в разы меньше.
Негодная аналогия. Кроме аналогии что то еще есть?
U>Вообще бы я вопрос шире поставил. Мне бы хотелось не только именованные туплы видеть, но и возможность задания шаблона не только для типа, но и для названий свойств/методов.
Это называется утиная типизация и ее много раз здесь уже обсуждали.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Имхо
Использовать стоит только в случае набора классов.
(new SomeClass1(), new SomeClass2())
иначе записи,
new {Value = 1, Text = "Something"}
по крайтей мере когда мейнстрим преодолеет каменный век и они таки получат распространение.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Undying, Вы писали:
U>>Не понял почему кортеж нужно ограниченно понимать только как замену out параметрам? AVK>Почему ограниченно? Это очень широкое применение.
Потребность в out'ных параметрах у меня возникает по очень большим праздникам. Кроме того я плохо понимаю, чем добавление неименованных tuple в язык принципиально улучшит ситуацию в сравнение с сегодняшних tuple, которые за пять минут пишутся на дженериках.
U>>Чем:
U>>
U>>inteface ITest
U>>{
U>> Name Name { get; }
U>>}
U>>
U>>Первый случай как бы не более понятен
AVK>По какой причине? Мне так второй более понятен, особенно при использовании.
В первом случае я могу быть уверен, что Name это простое хранилище FirstName и LastName, не имеющее неявной логики. Во втором случае объект типа Name может иметь любую логику, в том числе и весьма неочевидную для меня как пользователя этого объекта.
U>>Вообще бы я вопрос шире поставил. Мне бы хотелось не только именованные туплы видеть, но и возможность задания шаблона не только для типа, но и для названий свойств/методов.
AVK>Это называется утиная типизация и ее много раз здесь уже обсуждали.
Латентная, неявная или утиная типизация — вид динамической типизации, применяемой в некоторых языках программирования, когда границы использования объекта определяются его текущим набором методов и свойств, в противоположность наследованию от определёного класса.
Причем здесь это? Запись KeyValuePair<int, string, Key as Id, Value as Text> эквивалентна копипасту KeyValuePair с созданием класса IdTextPair со свойствами Id и Text, никакой совместимости между KeyValuePair и IdTextPair быть не должно. Такая фича нужна для того, чтобы за пять копеек получать классы с понятными названиями методов, сохраняющими все вкусности логики исходного класса (например, в простейшем случае это перекрытый Equals и GetHashCode). При этом от громоздкой записи легко избавиться либо через наследование, либо через полноценный псевдоним (т.е. using область видимости которого не текущий файл, а текущий namespace). Второе предпочтительней. Т.е. либо так:
class IdTextPair : KeyValuePair<int, string, Key as Id, Value as Text>
{
}
либо так:
namespace Test
{
using IdTextPair = KeyValuePair<int, string, Key as Id, Value as Text>;
}
Здравствуйте, Undying, Вы писали:
U>Потребность в out'ных параметрах у меня возникает по очень большим праздникам. Кроме того я плохо понимаю, чем добавление неименованных tuple в язык принципиально улучшит ситуацию в сравнение с сегодняшних tuple, которые за пять минут пишутся на дженериках.
Туплы добавляются не в язык, а в библиотеку, малой кровью, так сказать. Добавляются как раз с той целью, чтобы каждый разработчик не писал самокат. Да и чтобы стыковать решения на разных языках. Тот же F# туплами пользуется активно, и в том числе они будут торчать из его внешних интерфейсов, хочет этого кто-то или нет.
U>>>Чем:
U>>>
U>В первом случае я могу быть уверен, что Name это простое хранилище FirstName и LastName, не имеющее неявной логики. Во втором случае объект типа Name может иметь любую логику, в том числе и весьма неочевидную для меня как пользователя этого объекта.
Гибрид тупла с анонимным типом — вещь интересная, но это большой и не очевидный шаг для языка. И если фантазировать на эту тему, то чем пихать имена полей в дженерик параметры, я бы предпочел что-то в духе анонимного типа
{FirstName :string, LastName : string} Name { get; }
Но это уже вариации не на тему туплов, а на тему вытаскивания анонимных типов из метода.
Здравствуйте, samius, Вы писали:
S>Туплы добавляются не в язык, а в библиотеку, малой кровью, так сказать. Добавляются как раз с той целью, чтобы каждый разработчик не писал самокат. Да и чтобы стыковать решения на разных языках. Тот же F# туплами пользуется активно, и в том числе они будут торчать из его внешних интерфейсов, хочет этого кто-то или нет.
Т.е. мои возможности вообще никак не увеличаться, т.к. самокат у меня уже давным давно написан. Все-таки хотелось бы чтобы в новых версиях расширялись возможности языка, а не ограничивалось все новыми библиотеками и в лучшем случае синтаксическим сахаром.
S>Гибрид тупла с анонимным типом — вещь интересная, но это большой и не очевидный шаг для языка. И если фантазировать на эту тему, то чем пихать имена полей в дженерик параметры, я бы предпочел что-то в духе анонимного типа S>
S>{FirstName :string, LastName : string} Name { get; }
S>
S>Но это уже вариации не на тему туплов, а на тему вытаскивания анонимных типов из метода.
Я пока что обсуждаю то, что именованные кортежи в языке были бы полезны. Способ их декларации это уже другой вопрос, особых возражений против твоего способа записи у меня нет.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, samius, Вы писали:
S>>Туплы добавляются не в язык, а в библиотеку, малой кровью, так сказать. Добавляются как раз с той целью, чтобы каждый разработчик не писал самокат. Да и чтобы стыковать решения на разных языках. Тот же F# туплами пользуется активно, и в том числе они будут торчать из его внешних интерфейсов, хочет этого кто-то или нет.
U>Т.е. мои возможности вообще никак не увеличаться, т.к. самокат у меня уже давным давно написан. Все-таки хотелось бы чтобы в новых версиях расширялись возможности языка, а не ограничивалось все новыми библиотеками и в лучшем случае синтаксическим сахаром.
Да, стандартные туплы могли бы быть еще в C# 2.0. Обошлись бы без самокатов.
Здравствуйте, Undying, Вы писали:
U>Потребность в out'ных параметрах у меня возникает по очень большим праздникам.
Ну, кортежи тоже не так чтобы совсем часто применяются. Другое дело, что в языках с соотв. синтаксисом кортежи можно передавать в качестве параметра метода, что, по сравнению с out параметрами, в некоторых ситуациях уменьшает количество писанины очень сильно.
Кроме того, в некоторых языках, для достижения полной симметричности, у функций может быть один и только один параметр. В таких языках, как ты понимаешь, кортежи используются очень часто.
U> Кроме того я плохо понимаю, чем добавление неименованных tuple в язык принципиально улучшит ситуацию в сравнение с сегодняшних tuple, которые за пять минут пишутся на дженериках.
Ну, тут тебе просто надо посмотреть, как оно выглядит в поддерживающих их языках.
... << RSDN@Home 1.2.0 alpha 4 rev. 1245 on Windows 7 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Undying, Вы писали:
U>>Потребность в out'ных параметрах у меня возникает по очень большим праздникам.
AVK>Ну, кортежи тоже не так чтобы совсем часто применяются. Другое дело, что в языках с соотв. синтаксисом кортежи можно передавать в качестве параметра метода, что, по сравнению с out параметрами, в некоторых ситуациях уменьшает количество писанины очень сильно. AVK>Кроме того, в некоторых языках, для достижения полной симметричности, у функций может быть один и только один параметр. В таких языках, как ты понимаешь, кортежи используются очень часто.
U>> Кроме того я плохо понимаю, чем добавление неименованных tuple в язык принципиально улучшит ситуацию в сравнение с сегодняшних tuple, которые за пять минут пишутся на дженериках.
AVK>Ну, тут тебе просто надо посмотреть, как оно выглядит в поддерживающих их языках.
В Питоне, например, так:
def func(x,y):
# code to compute a and b
return (a,b)
(a,b) = func(1,2)
В сравнении с вариантом из сегодняшнего шарпа:
Tuple<double, double> func(double x, double y)
{
return _.Tuple(x, y);
}
var result = func(1,2);
вариант Питона лучше только одним, возможностью лаконично, но явно скастить возвращаемый тупл к туплу с произвольным названием полей. Это, конечно, лучше чем ничего, но один из главных принципов программирования — "код должен быть самодокументируемым" по-прежнему нарушается. В Питоне точно также как в шарпе при использовании функции возвращающей тупл нужно магическим образом догадываться, что именно хранит конкретное поле тупла. Именованные туплы позволили бы писать самодокументированный код, сохраняя все преимущества неименнованных туплов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Кроме того, в некоторых языках, для достижения полной симметричности, у функций может быть один и только один параметр. В таких языках, как ты понимаешь, кортежи используются очень часто.
Не часто, так как в таких языках (ml, haskell) обычно поддерживается карринг. Кортежи наоборот мешают каррингу, поэтому использование их в качестве аргументов (кроме конечно случаев когда нужен именно кортеж) считается плохим стилем.
Здравствуйте, Undying, Вы писали:
U>вариант Питона лучше только одним, возможностью лаконично, но явно скастить возвращаемый тупл к туплу с произвольным названием полей. Это, конечно, лучше чем ничего, но один из главных принципов программирования — "код должен быть самодокументируемым" по-прежнему нарушается.
А так?
def new_point(x, y):
# code to compute a and breturn (a,b)
U>В Питоне точно также как в шарпе при использовании функции возвращающей тупл нужно магическим образом догадываться, что именно хранит конкретное поле тупла. Именованные туплы позволили бы писать самодокументированный код, сохраняя все преимущества неименнованных туплов.
Именованные туплы это по сути обычные сишные структуры, они и так есть.
Здравствуйте, FR, Вы писали:
U>>вариант Питона лучше только одним, возможностью лаконично, но явно скастить возвращаемый тупл к туплу с произвольным названием полей. Это, конечно, лучше чем ничего, но один из главных принципов программирования — "код должен быть самодокументируемым" по-прежнему нарушается.
FR>А так? FR>
FR>def new_point(x, y):
FR> # code to compute a and b
FR> return (a,b)
FR>
Т.е. функцию возращающее имя человека в виде тупла ты предлагаешь назвать GetFirstNameAndLastName? В принципе при использовании неименнованных туплов это часто лучший вариант, но малость не лаконичный при использовании.
Не шибко красиво честно скажем.
U>>В Питоне точно также как в шарпе при использовании функции возвращающей тупл нужно магическим образом догадываться, что именно хранит конкретное поле тупла. Именованные туплы позволили бы писать самодокументированный код, сохраняя все преимущества неименнованных туплов.
FR>Именованные туплы это по сути обычные сишные структуры, они и так есть.
Чтобы написать обычную сишную структуру, да еще и желательно с перекрытием Equals и GetHashCode, чтобы не получить в будущем граблей, нужно написать кучу кода. Именованные туплы позволили бы делать тоже самое половиной строчки кода.
U>Т.е. функцию возращающее имя человека в виде тупла ты предлагаешь назвать GetFirstNameAndLastName? В принципе при использовании неименнованных туплов это часто лучший вариант, но малость не лаконичный при использовании.
FR>>Именованные туплы это по сути обычные сишные структуры, они и так есть.
U>Чтобы написать обычную сишную структуру, да еще и желательно с перекрытием Equals и GetHashCode, чтобы не получить в будущем граблей, нужно написать кучу кода. Именованные туплы позволили бы делать тоже самое половиной строчки кода.
Если нам не помогут, то мы тоже никого не пощадим.
