и нет, public_send ругается не на приватный метод, а неизвестный вообще

и это 2.4.0 — до сих пор кривоваты рефайны на мой взгляд, недоработаны

кто юзал rails 5 api application?

меня огорчило, что методы из рефайна не видны нормальным способом respond_to? — хер public_instance_methods — нет даже public_send — exception а вот send сработал просто не хотел его

методы из рефайна не просто не видны, они вообще недоступны за пределами своего скоупа так или иначе.

и это 2.4.0 — до сих пор кривоваты рефайны на мой взгляд, недоработаны

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

методы из рефайна не просто не видны, они вообще недоступны за пределами своего скоупа так или иначе.

в скоупе с using не видны

что?

что?

В каком скоупе?

в котором вызывается using

в модуле/классе который делает using видно все что рефайнит этот using

и нигде дальше.

Даже в потомках манкипатчах и так далее.

Только в пределах того же файла и того же скоупа где using использовался. Я не понимаю о чем ты.

в модуле/классе который делает using видно все что рефайнит этот using

нет, не видно смотри, я под «видно» подразумеваю не «работает» работает-то работает, да

меня огорчило, что методы из рефайна не видны нормальным способом respond_to? — хер public_instance_methods — нет даже public_send — exception а вот send сработал просто не хотел его

но в нём же эти способы проверки наличия не работают

а зачем им работать?

то есть 'foo'.camelize работает, а 'foo'.respond_to? :camelize — нет, например

а зачем им работать?

действительно. почему тогда send работает, а public_send — нет? это всё баги

какая разница? это же refinements

send работает потому что так MRI устроен

не понимаю почему ты упорно пытаешься обойти refinements

не понимаю почему ты упорно пытаешься обойти refinements

я не обойти, я хочу их видеть в тех же public_instance_methods в скоупе, где есть using

зачем?

зачем тебе их видеть?

ну вот надо для тестирования

увидеть их это и значит обойти, имхо.

почему их нет?

нет

Нет это не надо для тестирования.

Тестировать надо как раз не это.

нет, надо

нет, это

Не то что они есть, а то что они работают.

мне — это

вот именно что ты пытаешься обойти.

работают, когда сам делал. когда чужие — достаточно наличия

нет, не обойти

я их хочу использовать _полноценно_

Увидеть их, проверить что они есть это и значит обойти

так

Ну так дерни метод из refinement, вот тебе и полноценно

«обойти» в смысле «перебрать»?

или «избежать»?

Насколько я понимаю, идея refinements как раз в том чтобы быть как можно менее заметными.

Метод есть? он работает? больше ничего не нужно.

Все остальное это попытка движком обойти движок.

Ну так дерни метод из refinement, вот тебе и полноценно

это «в лоб», полноценно — когда работает всё

все это что?

Метод есть? он работает? больше ничего не нужно.

почему это «больше ничего не нужно»? странное решение

все это что?

когда методы в данном скоупе ведут себя как обычные методы

потому что все остальное это не задача refinements

тебе нужен манкипатч

за пределами скоупа с using — пожалуйста

тебе нужен манкипатч

нееее

мне нужно в скоупе, но полноценная работа

что нее? ты пытаешься увидеть метод зачем то

рабочий метод и есть полноценная работа

все остальное это метамагия.

да, прикинь. метод есть, а public_send нет, забавно. а send есть

рабочий метод и есть полноценная работа

нет, это его прямое исполнение. с методами куча других действий существует

да, прикинь. метод есть, а public_send нет, забавно. а send есть

потому что метод не public

которые почему-то недоступны для рефайн-методов

Потому что это суть рефайнов, нет?

потому что метод не public

а почему он от ресивера работает?

и почему public_send ругается на несуществующий метод, а не приватный?

это всё баги

ERROR: S client not available

странно называть это багом, я уверен что это намеренное поведение.

refinements просто плохо дружит с метамагией, это скорее стоит принять как данность.

странно называть это багом, я уверен что это намеренное поведение.

и где оно описано же? почему такое странное намеренное поведение? что-то работает, что-то нет. это неполноценная работа. и я не вижу причин ей

чем оно странное? то что ты не видишь метода?

мне кажется, просто с refinements внутри куча нестандартной работы и костылей, и поленились (не успели) обработать все случаи

я тоже думаю что внутри это кучка костылей.

чем оно странное? то что ты не видишь метода?

да, что он есть, но кроме прямого вызова и через send я не могу с ним взаимодействовать

наверняка refinements и не предназначались быть продвинутыми в метамагии

Тогда начнется кучка вопросов

если бы ещё send не работал — я бы задумался, что так действительно запланированно но начерта тогда send работает? и не вижу причин так сильно резать рефайн-методы

что будет если я переопределю метод в refinements или еще что там сделаю?

возможно потому что руби всегда под капотом юзает send?

возможно потому что руби всегда под капотом юзает send?

хз

что будет если я переопределю метод в refinements или еще что там сделаю?

всегда есть кучка вопросов, которые можно решать

оставить как получается и корректировать поведение в нужное русло

ты упорно пытаешься из refinements сделать monkey patching

вот и юзай манкипатч

если есть унификация методов но тут какое-то жёсткое костылирование

вот и юзай манкипатч

ещё раз: мне нужно в скоупе

каком таком скоупе?

в любом, где нужно

include MyModule не?

в String? в скоупе этом? и каждый раз так писать?

хотя может действительно проще через манки-патчинг рефайнментс переписать

Я сейчас настраиваю свой git для работы с несколькими bitbucket акаунтами через ssh протокол. Смотрю свой bashrс там строчка eval(ssh-agent -s) зачем нужно -s и зачем вызывается ssh-agent?

eval на echo поменяй и посмотри что напишет

молчит)

ssh-agent -s напиши тогда ...

говорит, я скобочки ставил вместо обратных ковычек

какие-то переменный закидывает

Саша, а когда мы разговаривем с bitgucket то кто загружует в ssh-agent файлы которыми мы будем разговаривать?

Он тебе в stdout баш код рисует