среда, 27 января 2010 г.

[comp.prog.humour] Маразм крепчал: объектно-ориентированные аргументы командной строки

Вот такое вот новшество в MPlayerXP 0.7.95:

Renamed command-line arguments to be more object-oriented

Т.е. аргументы командной строки были переименованы чтобы быть более объектно-ориентированными. Это пять!

PS. Новость найдена на LOR-е.

18 комментариев:

jazzer комментирует...

а в чем конкретно эта объектная ориентированность выражается? А то примеров нету, может, это и осмысленный апдейт

eao197 комментирует...

А фиг ее знает, в чем может выражаться объектная ориентированность названий аргументов командной строки. Имхо, названия вообще не могут быть объекными или функциональными, это же названия.

jazzer комментирует...

Ну почему же не могут, вполне могут.
Например, программа состоит из модулей а, б и в (и их подмолудей), и опции называются соответственно: --а-опция1, --б-опция2, --в-опция5-подопция9.
Это ОО.
А можно плясать от функциональности программы, где а, б и в - это то, что программа делает, и настойки касаются конкретно этих линий исполнения (например, разные настройки для архивации/разархивации).

eao197 комментирует...

>опции называются соответственно: --а-опция1, --б-опция2, --в-опция5-подопция9.
Это ОО.


Ну тогда почтовые адреса -- это чистой воды ОО: город-улица-дом-квартира.

jazzer комментирует...

да, а что тебя смущает?

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

eao197 комментирует...

Меня смущает то, что я знаю две общепризнанные формулировки ООП. Поздняя звучит как-то так: "ООП -- это икапсуляция, наследование и полиморфизм". Более ранняя, высказанная Аланом Кеем: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

Исходя из этих опредений я не понимаю, как непрограммная сущность (то бишь название) может быть объектно-ориентированной.

jazzer комментирует...

Ты не подменяй ОО ООП.
Никто о ООП тут не говорит.
ОО бывает не только П, еще бывает, например, ОО-декомпозиция (и, в противовес, функциональная декомпозиция).

Они хотят показать свою систему как совокупность нескольких компонент, и каждая компонента имеет свой набор опций, и это отражено в именах. Вот и все ОО.

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

(это все мои спекуляции, я не знаю, что у них было и что стало, но я понимаю, что может стоять за ОО)

eao197 комментирует...

>ОО бывает не только П, еще бывает, например, ОО-декомпозиция (и, в противовес, функциональная декомпозиция).

Не бывает. ОО-декомпозиция и ОО-анализ -- это все части объектного подхода к разработке программ. Т.е. все это части процесса програмирования.

И пусть это моя зашоренность, и пусть меня закидывают тухлыми помидорами, но ОО названия -- это маразм.

jazzer комментирует...

Вообще-то ОО-анализ (и декомпозиция) замечательно живут и вне программирования.
Равно как и функциональные А и Д.
Последние очень востребованы, например, в анализе (b последующей оптимизации) бизнес-процессов (IDEF0). ОО там тоже очень кстати: композиция выражается в структуре предприятия, а наследование - в должностных инструкциях, которые друг друга включают.

eao197 комментирует...

>Вообще-то ОО-анализ (и декомпозиция) замечательно живут и вне программирования.

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

Т.е. всегда речь идет о каких-то динамических системах, где кто-то с кем-то взаимодействует. И мы устанавливаем правила этих взаимодействий.

Название чего-либо -- это статика. В нем ничего ни с чем не взаимодействует. И не может в принципе.

jazzer комментирует...

опции - это настройки и характеристики.
Это это настройки и характеристики процессов - это функционально-ориентированные опции, если объектов и подсистем - ОО.

eao197 комментирует...

>опции - это настройки и характеристики.

опции и названия опций -- это разные вещи.

Объективно есть опция, скажем, частота кадров. Это и настройка, и характеристика плеейра -- если такая опция есть, это должным образом характеризует его.

А вот название этой опции, будь то frame-rate, divx-frame-rate, ffmpeg-divx-frame-rate, vlc-divx-frame-rate -- это уже чистой воды субъективизм. Если кому-то кажется, что какое-то из них более ОО, чем другие -- ну что поделать, всяк сходит с ума по своему.

jazzer комментирует...

ну вот смотри, есть в плеере такой объект-подсистема - divx.
И все опции, относящиесая к этой подсистеме, начинаюбтся с divx. И получать список опций можно, например, опцией --divx-help.
Это не ОО?
Функциональную декомпозицию тут не придумать, потому что у плеера одна задача - играть файл.

В других программах может быть и функциональная декомпозиция, где пляшут не от подсистем, а от действий, которые хочет выполнить пользователь. И тогда будет опция --действие1--настройкаА, --действие1-настройкаБ, ну и --действие1-help для получения всего списка опций для данного действия.

Естественно, эти опции могут перекрываться.

Например, если у тебя есть опция --действие1-логирование, то логирование будет включено только для действия 1, и это может соответствовать включению опций --подсистема1-логирование и т.д. для любой подсистемы, которая принимает участие в этом действии, но только для действия1.
С другой стороны, если ты указываешь --подсистема1-логирование, то подсистема 1 будет логировать всегда, независимо от того, какой именно деятельностью занимается система в данный момент.

Вот тебе разница между ОО- и ФО-опциями.

Например, если твоя подсистема - это divx, а ты открыл файл не divx, то все ОО-опции, относящиеся к divx, будут программой проигнорированы, в отличие от (может быть тех же самых с логической точки зрения) опций, заданных для конкретного действия.


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

eao197 комментирует...

>И все опции, относящиесая к этой подсистеме, начинаюбтся с divx. И получать список опций можно, например, опцией --divx-help.
Это не ОО?


Ну не вижу я в названии "--divx-help" никакого ОО. ОО - это когда выделяется объект, который имеет строго определенный контракт и который скрывает от всех детали исполнения своего контракта. Далее объект имеет методы, которые дергаются для получения тех или иных результатов (согласно контракту).

В названии(!) нет никаких контрактов, название не является объектом, у него нет методов, его нельзя дергать.

Поэтому нельзя (с моей точки зрения) вести речь о объектной-ориентированности названий аргументов. Можно говорить о том, что аргументы отражают структуру приложения и еще какую-нибудь муть в том же духе.

Опять же, если --divx-help является ОО названием, то что на счет --help-divx? Или --divx-playback-help и --playback-help-divx, и --playback-divx-help?

jazzer комментирует...

так набор опций и есть контракт, это и есть интерфейс для взаимодействия с пользователем. Так что все вполне ОО - инкапсуляция на месте, наследование и полиморфизм реализуются через опции типа --decoder-frame-rate, где decoder - это базовый класс для всех декодеров, и все декодеры типа divx, xvid и т.д. должны реализоваывать весь набор этих базовых опций.

eao197 комментирует...

>так набор опций и есть контракт, это и есть интерфейс для взаимодействия с пользователем.

Мы, похоже, с тобой о разных вещах говорим. Набор опций -- это контракт плейера. Как набор публичных методов -- это контракт класса. С этим я не спорю, с этим все нормально.

Но в самом названии опции где ОО?

Вот если продолжать аналогию -- есть класс с методами установки и получения параметра транспорта. Эти методы -- это контракт класса. Пусть они назывались раньше setTransportParams и queryTransportParams. Потом их переименовали в transportSetParams и transportQueryParams. Можно ли здесь говорит о какой-нибудь объектности названий методов?

jazzer комментирует...

ну конечно, ты ведь говоришь пользователю, что в есть такой объект - транспорт.

Тут само наличие слова транспорт вскрывает объектное деление подсистемы, тем самым оно ОО.

eao197 комментирует...

>Тут само наличие слова транспорт вскрывает объектное деление подсистемы, тем самым оно ОО.

Не на такую широту взглядов я пока пойтить не могу.

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

:)))