Re[18]: Использование tuple
От: Undying Россия  
Дата: 08.10.09 07:45
Оценка:
Здравствуйте, FR, Вы писали:

U>>Т.е. функцию возращающее имя человека в виде тупла ты предлагаешь назвать GetFirstNameAndLastName? В принципе при использовании неименнованных туплов это часто лучший вариант, но малость не лаконичный при использовании.


U>>
U>>(firstName, lastName) = GetFirstNameAndLastName();
U>>


FR>Лаконичный чем твой генерик выше.


Если бы шарп поддерживал именнованные туплы, то использование функции бы выглядел так:

var name = GetName();
Console.WriteLine(name.FirstName);


Гораздо красивее, чем даже на питоне, не говоря уж о сегодняшнем шарпе.

FR>Ну это проблемы шарпа, в том же F# куча кода не нужна http://msdn.microsoft.com/en-us/library/dd233184(VS.100).aspx


Т.е. такая декларация класса

type Point = { x : float; y: float; z: float; }


автоматически перекрывает Equals и GetHashCode?

зы
Вообще я бы хотел даже не именованных туплов, а возможности создавать одной строчкой кода новый тип класса на основе существующего с возможностью переименование полей и методов. Тогда бы и потребность в специальной реализации (т.е. такой для которой не достаточно средств шарпа 2.0) туплов отпала и возможности языка увеличились бы кардинально. F# вроде ничего подобного не позволяет.
Re[8]: Использование tuple
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 08.10.09 10:13
Оценка:
Здравствуйте, IT, Вы писали:
IT>В общем, на мой взгляд эта проблема надумана.

Не надумана
Автор: Andrei N.Sobchuck
Дата: 26.03.07
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[9]: Использование tuple
От: IT Россия linq2db.com
Дата: 08.10.09 13:48
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>>В общем, на мой взгляд эта проблема надумана.

ANS>Не надумана
Автор: Andrei N.Sobchuck
Дата: 26.03.07


Мы об одной и той же проблеме говорим? Мы тут вроде о туплах, а ты мне ссылку на параметры лямбды
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Использование tuple
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.10.09 08:31
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>Мы об одной и той же проблеме говорим? Мы тут вроде о туплах, а ты мне ссылку на параметры лямбды


Суть одна и та же — поля не именованы. Если типы совпадают — туши свет.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[11]: Использование tuple
От: thesz Россия http://thesz.livejournal.com
Дата: 09.10.09 09:06
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, IT, Вы писали:


IT>>Мы об одной и той же проблеме говорим? Мы тут вроде о туплах, а ты мне ссылку на параметры лямбды


ANS>Суть одна и та же — поля не именованы. Если типы совпадают — туши свет.


Это не так.

Тип [(String,String)], который получился преобразованием Map.toList ourNameMap, проходит через обработку без всяких структурных изменений внутри пар. Поэтому это не "тушите свет", это, обычно, "следи чуть внимательней".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Использование tuple
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.10.09 09:24
Оценка:
Здравствуйте, thesz, Вы писали:

T>Тип [(String,String)], который получился преобразованием Map.toList ourNameMap, проходит через обработку без всяких структурных изменений внутри пар.


К чему тут Map.toList? И что вообще должно получиться в результате Map.toList (хоть к теме топика на прямую это и неотносится)?

T>Поэтому это не "тушите свет", это, обычно, "следи чуть внимательней".


Жаль, что нужно очень внимательно следить, чтобы не перейти грань между "тушите свет" и "следи чуть внимательней".
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[13]: Использование tuple
От: thesz Россия http://thesz.livejournal.com
Дата: 09.10.09 09:54
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, thesz, Вы писали:


T>>Тип [(String,String)], который получился преобразованием Map.toList ourNameMap, проходит через обработку без всяких структурных изменений внутри пар.


ANS>К чему тут Map.toList?


Удобная штука.

ANS>И что вообще должно получиться в результате Map.toList (хоть к теме топика на прямую это и неотносится)?


Список пар "ключ, значение".

T>>Поэтому это не "тушите свет", это, обычно, "следи чуть внимательней".

ANS>Жаль, что нужно очень внимательно следить, чтобы не перейти грань между "тушите свет" и "следи чуть внимательней".

Нет, не надо.

На 600 определений, у которых нет типа и для которых ghc показал типы с помощью -fwarn-missing-signatures в моей программе приходится 38 определений с кортежами, где что-то можно перепутать — (Double,Double,Double), ((Index,Bool),(Index,Index,Side)) и подобные. В паре (String,Int) и тройке (Bool,String,Int) ничего перепутать нельзя, поэтому я такие не учитывал.

Что составляет 6.3%.

Такие определения группируются, буквально, в двух файлах из 79. В остальных случаях это внутренние функции, на которые заводить отдельный тип смысла не имеет (ну, например, функция возвращает (Entry, TreeView, ListStore Param, TreeView, ListStore Function) и используется один раз — зачем для неё тип?).

Итого, менее 6% всех функций и менее 3% файлов требуют чуть более внимательного отношения.

И это в Хаскеле, где пары очень дёшевы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Использование tuple
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.10.09 10:12
Оценка:
Здравствуйте, thesz, Вы писали:

ANS>>К чему тут Map.toList?

T>Удобная штука.

Если tuples использовать только для пар ключ-значение, то проблем действительно не будет. Только tuples-как-сущность для этого не нужны.

T>Итого, менее 6% всех функций и менее 3% файлов требуют чуть более внимательного отношения.


10% кода могут породить 90% багов И вообще, странно слышать аргумент про "требуют чуть более внимательного отношения" от человека предпочитающего статическую типизацию перед динамической из-за возможности получить ошибку приведения типов во время выполнения.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re: Использование tuple
От: Gaperton http://gaperton.livejournal.com
Дата: 09.10.09 10:13
Оценка:
Здравствуйте, IDL, Вы писали:

IDL>В FW 4 появился новый тип tuple, перенятый с функциональных языков.

IDL>В общем понятно предназначение его — получить возможность вернуть более одного параметра из функции.
IDL>Но насколько это делает код более понятным, ведь значения возвращаемые из tuple без именные.
IDL>Что можно понять глядя на функцию возвращающую tuple?

А что можно понять, глядя на вызов такой функции?

res = fun( x, y, z );

?

А если ее сигнатура такая:

Type fun( Type &, Type, Type & )

А теперь то же самое с туплами (синтаксис беру с тех языков, где это поддержано давно):

( res, x, z ) = fun( y );

Неужели не понятнее, что происходит, без сигнатуры функции?
Re[2]: Использование tuple
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 09.10.09 10:31
Оценка: +1
Здравствуйте, Gaperton, Вы писали:


G>Type fun( Type &, Type, Type & )

G>( res, x, z ) = fun( y );

Разница между 1 и 2 в том, что точек присваивания много, и в каждом будут свои имена, а точка реализации функции одна.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: Использование tuple
От: Gaperton http://gaperton.livejournal.com
Дата: 09.10.09 10:33
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Неужели не понятнее, что происходит, без сигнатуры функции?


Или у кого-то хватило ума добавить туплы без поддержки паттерн-матчинга, и так как я написал — писать нельзя? И оно выглядит в духе std::pair в С++ — криво, как турецкая сабля? Такой тупл реально бесполезен почти .
Re[15]: Использование tuple
От: thesz Россия http://thesz.livejournal.com
Дата: 09.10.09 10:48
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, thesz, Вы писали:


ANS>>>К чему тут Map.toList?

T>>Удобная штука.
ANS>Если tuples использовать только для пар ключ-значение, то проблем действительно не будет. Только tuples-как-сущность для этого не нужны.

Кортежи нужны в других местах, для пар "ключ, значение" они используются потому, что удобны.

Однако ты пропустил основной мотив моего комментария: обычно пары проходят через обработку без структурных изменений. Какая пара была на входе, такая получится и на выходе. Поэтому ошибок с перестановками добиться тяжело.

T>>Итого, менее 6% всех функций и менее 3% файлов требуют чуть более внимательного отношения.


ANS>10% кода могут породить 90% багов


Значит, их надо переписать.

И они будут переписаны, если это действительно поможет избежать ошибок.

ANS>И вообще, странно слышать аргумент про "требуют чуть более внимательного отношения" от человека предпочитающего статическую типизацию перед динамической из-за возможности получить ошибку приведения типов во время выполнения.


Для меня важно поменьше напрягаться, а не соблюдать все 613 законов статической типизации.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Использование tuple
От: IT Россия linq2db.com
Дата: 09.10.09 13:21
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

IT>>Мы об одной и той же проблеме говорим? Мы тут вроде о туплах, а ты мне ссылку на параметры лямбды


ANS>Суть одна и та же — поля не именованы. Если типы совпадают — туши свет.


В параметрах лябды тоже тушим свет? Да и вообще при вызове любого метода при передаче параметров легко запутаться. Ага.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Использование tuple
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.10.09 14:35
Оценка: 27 (4) +2
Здравствуйте, _FRED_, Вы писали:

_FR>Кстати, а как в функциональных языках (в первую очередь, .NET-ных): принято ли использовать таплы в public API или рекомендуется использовать их только в локальных переменных и методах?


Смотря что за операция. Например, если функция (метод) разделяет список на два других, то совершенно естественно описать ее сигнатуру следующим образом:
public Partition (pred : T -> bool) : list [T] * list [T]

Или вот сигнатура метода отделяющего последний элемент списка от списка:
public DivideLast () : list [T] * T


Короче, все нормально, если разумно. Не разумно возвращать в кортежах поля каких-нибудь бизнес-сущностей. А если из сути функции понятно, что она возвращает, то проблем это не создает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Использование tuple
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.10.09 14:42
Оценка: 2 (1)
Здравствуйте, IDL, Вы писали:

AVK>>Для нормального использования кортежей нужен язык с соответствующим синтаксисом.

IDL>Не совсем понятно о какой поддержке идёт речь

Как минимум нужны две возможности:
1. Конструирование кортежа, чтобы вместо:
Tuple.Create(1, "abc")

писать просто:
(1, "abc")
2. Декомпозиция кортежа, чтобы вместо:
  def t     = GetNameAdnCount();
  var name  = t.Item2;
  var count = t.Item1;

можно было писать:
  def (count, name) = GetNameAdnCount();

или даже:
  SetNameAdnCount(GetNameAdnCount());


В общем, сахар который позволяет удобно ими манипулировать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Использование tuple
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.10.09 14:45
Оценка: +2
Здравствуйте, IDL, Вы писали:

IDL>Я тоже столкнулся именно с такими проблемами и пришёл к таким выводам.

IDL>С одной стороны не надо на каждый чих создавать объект, но сдругой не сразу и поймёшь, что вернул.

Не обижайтесь, но это говорит о не внятности ваших функций. Например, кому не ясно значение следующего метода list[T]?
    public Partition (pred : T -> bool) : list [T] * list [T]
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Использование tuple
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.10.09 14:47
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Или у кого-то хватило ума добавить туплы без поддержки паттерн-матчинга,


У Майкрософт. Ты тему то прочел?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Использование tuple
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.10.09 14:50
Оценка: +2
Здравствуйте, Gaperton, Вы писали:

G>А что можно понять, глядя на вызов такой функции?


G>res = fun( x, y, z );


G>?


В таком виде конечно разницы никакой, так как функция (и скорее всего ее параметры) названа в худших традициях функциональщиков.

Если же функция имеет нормально описанный список параметров, то перейдя к ней или посмотрев ее сигнатуру с помощью интеллисенса можно будет понять все что нужно о ее аргументах.
С кортежам все сложнее. Тут или имя функции должно однозначно говорить о том, что за элементы у этого кортежа, или требуется наличие качественного описания функции. Второй вариант, на мой взгляд уже является плохим. Так что кортежи хороши только там где из значение очевидно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Использование tuple
От: maxkar  
Дата: 09.10.09 15:18
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Например, кому не ясно значение следующего метода list[T]?

VD>
VD>    public Partition (pred : T -> bool) : list [T] * list [T] 
VD>


Мне не ясно, например. Кто первый в этой паре? То, что соответствует предикату или то, что не соответствует? И, самое интересное. Как я должен рассуждать, чтобы получить "правильный" ответ? Документацию я специально не смотрел и на шарпе не пишу.
Re[5]: Использование tuple
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.10.09 19:13
Оценка: +1 -1
Здравствуйте, maxkar, Вы писали:

VD>>Например, кому не ясно значение следующего метода list[T]?

VD>>
VD>>    public Partition (pred : T -> bool) : list [T] * list [T] 
VD>>


M>Мне не ясно, например. Кто первый в этой паре?


Бывает. Наверно в школе с учебниками математики тоже проблемы были?

M> То, что соответствует предикату или то, что не соответствует?


Разумеется сначала идут те что соответствуют, потом те что не соответствуют.

M>И, самое интересное. Как я должен рассуждать, чтобы получить "правильный" ответ? Документацию я специально не смотрел и на шарпе не пишу.


А как ты рассуждаешь когда используешь функцию Filter или Where? А в друг результат будет обратный предикату?

В реальном коде все выглядеть примерно так:
def (fresh, old) = data.Partition(x => x.DateTime.Year >= DateTime.Now.Year);
...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.