CM
вообще, это имеет смысл для конструкторов
Size: a a a
2021 February 04
A
ну раз метод то почему не смаленькой? стиль автора?
CM
вот потому что конструктор
AG
bisect оч веселая вещь - работал всю ночь и до сих пор не закончил
а сколько времени занимает все тесты прогнать обычно?
CM
AR
а сколько времени занимает все тесты прогнать обычно?
Минут пять
CM
ну раз метод то почему не смаленькой? стиль автора?
irb(main):001:1* Float(1)
=> 1.0
irb(main):002:0> Kernel.method(:Float)
=> #<Method: Kernel.Float(arg, exception: ...) <internal:kernel>:171>
не то чтоб новая практика
AG
Минут пять
тогда не может быть вся ночь. Можно выключить и запустить еще раз с
--verbose, чтобы посмотреть не ходит ли оно по кругуAG
ну и после остановки у него какой-то отчет вроде бы должен быть
A
вот потому что конструктор
То есть ведет себя также как Array(), Hash() и тп?
AR
тогда не может быть вся ночь. Можно выключить и запустить еще раз с
--verbose, чтобы посмотреть не ходит ли оно по кругуну, говорю что вижу
AG
ну, говорю что вижу
я имел в виду, что в норме не может быть )
что-то пошло не так
что-то пошло не так
CM
То есть ведет себя также как Array(), Hash() и тп?
смотря какое поведение наблюдаем
Array / Hash / Integer / Float и т.п. занимаются приведением типов. Конструкторы схем — нет
Но все эти функции принимают на вход что-то значимое и выплёвывают объект конкретного типа или кидают исключение
Array / Hash / Integer / Float и т.п. занимаются приведением типов. Конструкторы схем — нет
Но все эти функции принимают на вход что-то значимое и выплёвывают объект конкретного типа или кидают исключение
A
Array / Hash / Integer / Float и т.п. занимаются приведением типов. Конструкторы схем — нет
ну вот у меня по этому и возник вопрос. Ну и так-то все функции принимают что-то значимое на вход если принимают и некоторые выплевыввают объекты. Это же не значит что надо их все именовать с большой буквы? Или есть спецификация какая-то в руби?
Кстати касательно стиля в dry. Там по синтаксису использование .() вместо .call идет вразрез с RuboCop::Cop::Style::LambdaCall
приходится сразу в игнор правило заносить
ну вот у меня по этому и возник вопрос. Ну и так-то все функции принимают что-то значимое на вход если принимают и некоторые выплевыввают объекты. Это же не значит что надо их все именовать с большой буквы? Или есть спецификация какая-то в руби?
Кстати касательно стиля в dry. Там по синтаксису использование .() вместо .call идет вразрез с RuboCop::Cop::Style::LambdaCall
приходится сразу в игнор правило заносить
AD
Array / Hash / Integer / Float и т.п. занимаются приведением типов. Конструкторы схем — нет
ну вот у меня по этому и возник вопрос. Ну и так-то все функции принимают что-то значимое на вход если принимают и некоторые выплевыввают объекты. Это же не значит что надо их все именовать с большой буквы? Или есть спецификация какая-то в руби?
Кстати касательно стиля в dry. Там по синтаксису использование .() вместо .call идет вразрез с RuboCop::Cop::Style::LambdaCall
приходится сразу в игнор правило заносить
ну вот у меня по этому и возник вопрос. Ну и так-то все функции принимают что-то значимое на вход если принимают и некоторые выплевыввают объекты. Это же не значит что надо их все именовать с большой буквы? Или есть спецификация какая-то в руби?
Кстати касательно стиля в dry. Там по синтаксису использование .() вместо .call идет вразрез с RuboCop::Cop::Style::LambdaCall
приходится сразу в игнор правило заносить
Всегда можно
.=== использовать, вместо .()CM
> Это же не значит что надо их все именовать с большой буквы?
нет, но конструкторы бывает полезно
> Кстати касательно стиля в dry. Там по синтаксису использование .() вместо .call идет вразрез с RuboCop::Cop::Style::LambdaCall
приходится сразу в игнор правило заносить
а зачем заносить? никто ж не мешает использовать у себя в проекте call
нет, но конструкторы бывает полезно
> Кстати касательно стиля в dry. Там по синтаксису использование .() вместо .call идет вразрез с RuboCop::Cop::Style::LambdaCall
приходится сразу в игнор правило заносить
а зачем заносить? никто ж не мешает использовать у себя в проекте call
CM
я пишу как пишу, рубокоп всё фиксит
CM
мне тут тяжело о чём-то говорить, потому что использовать методы с большой буквы для конструкторов это настолько естественно, что вопросов даже не возникало
VD
Array / Hash / Integer / Float и т.п. занимаются приведением типов. Конструкторы схем — нет
ну вот у меня по этому и возник вопрос. Ну и так-то все функции принимают что-то значимое на вход если принимают и некоторые выплевыввают объекты. Это же не значит что надо их все именовать с большой буквы? Или есть спецификация какая-то в руби?
Кстати касательно стиля в dry. Там по синтаксису использование .() вместо .call идет вразрез с RuboCop::Cop::Style::LambdaCall
приходится сразу в игнор правило заносить
ну вот у меня по этому и возник вопрос. Ну и так-то все функции принимают что-то значимое на вход если принимают и некоторые выплевыввают объекты. Это же не значит что надо их все именовать с большой буквы? Или есть спецификация какая-то в руби?
Кстати касательно стиля в dry. Там по синтаксису использование .() вместо .call идет вразрез с RuboCop::Cop::Style::LambdaCall
приходится сразу в игнор правило заносить
Нет никакой спецификации, просто dry-ребята "так видят"; у них свой взгляд на читабельность кода. Взять хотя бы повсеместное подключение динамических (можно даже сказать, "параметризованных") модулей.
Считай, что это диалект (как, например, Seattle Ruby). Руби — гибкий язык, каждый пишет, как ему нравится. RuboCop примерно отражает стиль большинства, но это не отменяет "оппозицию".
Считай, что это диалект (как, например, Seattle Ruby). Руби — гибкий язык, каждый пишет, как ему нравится. RuboCop примерно отражает стиль большинства, но это не отменяет "оппозицию".
A
понял, спасибо