а що не так,

@hate-engine TIL

ну каэш, давайте value-type типы наследовать от объектов и наслаждаться быстротой-жаватой

Кстати, поясните, if норм или тоже не ооп?

@plhk ти що, читати не вмієш: >stop for a minute and double-check your design. >*Perhaps* you can make a polymorphic call instead.

@hate-engine Да это понятно, я чисто теоретически спрашиваю.

@plhk ненорм на самом деле, только это уже не не ооп, а не функционально + не типо-теоретично: http://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ tl;dr: лущ патерн-матчить вместо ифов, так легщ верифицировать коректность кода; каждый твой иф не учитывает *СМЫСЛ* полученного булеана, и тебе его нужно держать в голове (хотя это легко может помнить машина!) в обоих разветвлениях control flow, плюс то же для всех уровней вложенности текущего скоупа. ну и вообще, мне лично давно не нравятся применения булеана там, где изначально нужен ADT с двумя нуль-арными конструкторами. В принципе, норм, когда такой тип `data SuccessCode = Success | Failure` заменяют на подобающе обозванный бул: `isSuccess : Bool` — но это окрашивается в отчетливый меркаптаново-сероводородных запах в случае `data AuthMethod = Radius | Tacacs`. Да, этот enum из двух констант точно так же изоморфен булу `data Bool = True | False`, но вот такое применения була (`isAuthRadius : Bool`) пахнет просто пиздец

@anonymous пук

@anonymous switch это и есть патерн матчинг для быдла

@hate-engine поперди мне тута

@plhk речь о том, что патерн-матчинг сохраняет лексически декомпозицию исходных данных по рантаймовым вариантам, что делает тот же наболевший NPE analysis тривиальным наколенным упражнением а if не сохраняет — чтоб доказывать что-то внутри then-else веток, уже нужен sat-солвер (NP-полный в общем случае)

@ulidtko чо. "if C then T else E" = "match C with [ True -> T | False -> E]".