Я не даю это как решение. Просто как способ куда еще можно посмотреть. Тем более что у меня Linux,
и синтаксис AT&T (операнды свапнуты наоборот). Вобщем это подсказка.
Sasha_88, я думаю что щас в топик зайдет настоящий Objective-C -шник и будет нас бить. Я предлагаю взять паузу и поискать пруфы или примеры как там это работает. Возможно под наследованием Objective понимает нечто более другое чем С++ например. Может прототипирование.
Román Mirilaczvili, фичу завезли? Звучит как колбасу завезли. Или хлеб.
Дорогой мой. Для баз данных - недостаточно завезти новый тип данных.
Нужно хотя-бы обеспечить индексирование каждого нового типа
данных будь то XML, JSON или бог его знает какой yaml.
Sasha_88, я не знаток Objective C. Я-бы спрашивал не зачем это надо а к каким последствиям может привести. Например класс C имел поля которые надо было инициализировать. Что с ними будет в этом случае? Чем мы их инициализируем?
Я ещё сомневаюсь что тут вообще указаны агрументы а не типы возвращаемых значений
Тут не аргументы а обобщенные типы. Если ты в С++ кодил - то там есть шаблоны. Это наиболее близкое. В данном случае a и b означает некие типы a и b такие что верна декларация map :: (a -> b) -> [a] -> [b]
По поводу Python. В нем типизация явно не выражена. Это создает проблемы для новичков. Сначала им кажется что всё очень легко и Python всеяден. Тоесть потребляет любые аргументы. Я вот когда изучал Python - постоянно советовался с функцией type которая возвращает тип. Например.
>>> x = [1,2,3]
>>> type(x)
class 'list'
В данном случае Python видит что тип - список но не видит список чего. Это создает некую вольность
для рантайма.
В противоположность Haskell
Prelude> x = [1,2,3]
Prelude>
Prelude> :t x
x :: Num a => [a]
Видит что [a] это список таких элементов имеющих тип Num (числовой). И это накладывает ограничения.
В фазе компилляции Haskell может проверять куда этот список можно передать а куда - нет.
Вообще Haskell часто считают эталлоном типизированного компиллятора. И если вы решили изучать его после Python - то вам надо сломать сознание. Будет трудно. Я гарантирую это.
plyk, есть такая поговорка - плотник думает топором. Вот если ты знаешь Python - то посмотри как декларирована функция map. Возможно тебе так будет понятнее.
А лямбда я сам для себя объяснял как типизированный указатель на функцию. Так проще. Идёшь от понимания через те абстракции которые уже известны.
Николай Савельев, ты-б послушал опытного. Вообще HTML имеет больше уровней семантики чем просто тект. Я например могу создать html (абсолютно валидный) который на экране будет иметь "world" в нужных тегах но ты его регулярками не найдешь. И дело даже не в том что надо сбить спесь с зазнавшегося школьника. Просто жизнь или исходные данные могут однажды тебя неприятно шокировать.
Поэтому слушай что советуют и сам не включай менторский тон.
Если их сложно или невозможно формализовать - то тогда наверное реляционная БД не нужна. А нужна документно-ориентированная. Типа MongoDb. Она нормально глотает такие слабо-специфицированные таблицы.
Можно также эти все атрибуты положить в поле типа BSON под Postgresql но работать вам придется используя более сложный диалект языка который работает с JSON.
Теория реляционных БД также иногда предлагает модель EAV для хранения списков свойств сущности. Но с EAV очень неудобно работать практически. Кроме того EAV плохо работает под нагрузкой. Тратит много времени на сборку всех атрибутов сущности. Поэтому ее можно смотреть в очень уж академических или ненагруженных юзкейсах.
Антон, лет 5 назад я создавал акк. Там есть пробный период типа 30 дней. За этот период можно понять нужен ли вам конфлуенс или нет. А дальше надо что-то платить.
Я не даю это как решение. Просто как способ куда еще можно посмотреть. Тем более что у меня Linux,
и синтаксис AT&T (операнды свапнуты наоборот). Вобщем это подсказка.
И не создавай форков. Это некрасиво.