Тяжелый ООПшный майндфак

[metaclass]

В .NET, во всяком случае в 2.0 и раньше есть одна вещь, которая садит на коня просто нечеловечески. Это то, что куча функций обработки строк является методами экземпляра класса String. А не статическими методами класса. Вроде бы мелочь, подумаешь, какая разница - писать s=s.ToLower(); или s=string.ToLower(s);
А вот хрен. С добавлением того факта, что строка это объект, и она может быть null, и использованием этого null как маркера "функция вернула хрень" в куче мест фреймфорка мы получаем тот геморрой, что перед каждым вызовом s.ToLower() приходится впихивать if(!string.IsNullOrEmpty(s)) или как минимум if(s!=null).

Т.е. вместо такого:
if(String.ToLower(Path.GetExtension(fn))==".wav") {
}

приходится писать такое:
string ext = Path.GetExtension(fn);
if(!string.IsNullOrEmpty(ext))
ext = ext.ToLower();
if(ext==".wav"){
}


Вот этот ООПшный фетишизм "все - объект" и отсутствие глобальных или хотя бы статических функций для простейших вещей просто бесит.

Comments

[kkirsanov.livejournal.com]

В питоне встречается похожее:

Если есть список строк: a=['a', 'b', 'c'] и хочется их обеденъить в одну строку 'abc' то нужно писать "".join(a)

"" - создаст пустую строку для которой уже будет вызываться join

[184467440737095.livejournal.com]

а если хочется объединить 'a', 'b', 'c'] в строку 'a,b,c', то нужно писать ','.join(a), что выглядит вполне логично.

[rssh.livejournal.com]

В С# вроле элвис есть. Должон немного помогать

[http://users.livejournal.com/_windwalker_/]

Кстати, а в .NET нет .equalsIgnoringCase() ?
Тогда бы код ребе превратился бы в вот такой:
string ext = Path.GetExtension(fn);
if (".wav".equalsIgnoringCase(ext)) {
//foobar!
}

[metaclass.livejournal.com]

Есть, но он там с извращениями тоже. И в switch его не засунешь.

[vp.livejournal.com]

Вообще я очень слабо понимаю, что движет проектировщиками, когда не выносят такие вещи на уровень статических членов класса.. Это ж банально нудобно. Я понимаю, что тотальное ООП и все такое, но должна ж быть грань.

[metaclass.livejournal.com]

Фетишизм ими движет. Им там в микрософте запрещают одевать на работу кожано-латексную одежду и приносить своих любимых японских кукол, так они в качестве суррогатного фетиша используют ООП.

[vromanov.livejournal.com]

Это просто стиль.. Можно писать двумя способми
string.ToUpper(string.Trim(s))
s.Trim().ToUpper()
второй несколько короче.

[jek-hor.livejournal.com]

А как себя должен вести метод класса, если ему подсунули NULL вместо кошерного объекта?

[metaclass.livejournal.com]

Как всякая уважающая себя монада - выдавать null на выходе :)

[alexey-rom.livejournal.com]

А ему не должно быть возможности "подсунуть NULL вместо кошерного объекта". Или nil -- кошерный объект (как в Ruby), или нельзя его допускать куда ни попадя.

[jek-hor.livejournal.com]

А в руби можно сказать так:

irb(main):004:0> nil.to_s.downcase
=> ""


:)

[metaclass.livejournal.com]

Языки без строгой типизации это еще один ад.

nil, to_s и downcase какого типа?

[dizel-by.livejournal.com]

Ты бы ещё перл вспомнил :)

[mibori.livejournal.com]

оффтопик.

интересно, выражение "садит на коня"/"подсел на коня" употребляют только мои Минские знакомые :)
Знакомые к примеру из Курска, Москвы, Питера, Новосибирска такое выражение не употребляют.
Когда я первый раз столкнулся, не понял о чем речь и пришлось спрашивать :)

[metaclass.livejournal.com]

Странно, вроде ничего локально-местного в выражении нету :)

[kurilka.livejournal.com]

можно переспросить?

[potan.livejournal.com]

Не надо использовать null. Проще всего использовать фиксированную строку, например пустую.
Для нефинальных классов можно завести потомка, все методы которого будут возвращать ошибку, и использовать его экземпляр в качестве null.

[metaclass.livejournal.com]

Это надо в мозги архитекторам дотнета вколотить - у них там где нул, где пустые строки, что попало, в общем.

[sergiej.livejournal.com]

В жабе просто ".wav".equals... и все дела. И нулл нужен, пустая строка не есть отсутствие строки.

[alexey-rom.livejournal.com]

Но и отсутствие строки не есть строка. Так что переменной типа string не должно быть возможно присвоить значение "отсутствие строки" или вернуть его из метода. Но этот поезд давно ушёл :(

[wizzard]

Extension methods to the rescue. Смотрится вполне пристойно в итоге.

Там можно и на null this проверять, вроде.

Кроме того, никто ж не мешает написать свои строки, если совсем туго станет :)

[alexey-rom.livejournal.com]

Но они всё равно будут nullable :( struct-ами ведь их не сделать.

[nivanych.livejournal.com]

Что ж так всё страшно!
Я-то уж собирался раз и навсегда
вернуться обратно в объектно-ориентированному,
даже уже думал, как бы терминальные F,G-диалгебры
приспособить для моделирования интерфейсов.
А тут! Это попытка расжигания меж...межжж какой...
В общем, розни!
;-) ;-)

[metaclass.livejournal.com]

Ну, может если построить свое ООП с блекджеком и шлюхами элементами ФП, то и лучше получится :)

[ennor.livejournal.com]

Это работа потомков тех самых коммунистов, которые в свое время придумали SmallTalk.

ЗЫ Вообще, посидев несколько лет на мультипарадигмальных языках типа SQL, я сейчас с трудом понимаю, зачем нужны все остальные :)

[adontz.livejournal.com]

Метод есть, но не в System.String, а в CultureInfo.TextInfo

[alexey-rom.livejournal.com]

Бесит то, что объекты любого типа вообще могут быть null и соответственно "использование этого null как маркера". То есть недостаточное количество ООП-фетишизма :)