InstanceMethods (ActiveSupport::Concern) deprecated w Rails 3.2

https://github.com/rails/rails/commit/401393b6561adc1ce7101945163c9601257c057a#activesupport/lib/active_support/concern.rb

Na co? Po co? Stoją za tym jakieś głębsze przemyślenia, coś to poprawia? Czy tylko chcą nam życie uprzykrzyć żeby po upgradzie appka wywaliła dziesiątki DEPRECATION WARNING?

Znaczy rozumiem, że zaoszczędzamy jedną linijkę w module Concern (zamiast której mamy 5 rzucających warning :D)

base.send :include, const_get("InstanceMethods") if const_defined?("InstanceMethods")

Jaki sens ma to teraz, kiedy wszystkie gemy, appki itd. używają już wersji z InstanceMethods?

Commit co prawda stary i wiedziałem o nim wcześniej, ale jakoś nie bolało mnie to do dzisiaj, dopóki nie zrobiłem upgrade-u do 3.2 :smiley:

Nie szukaj sensu we wszystkim co zmieniają w Railsach :slight_smile:

To akurat ma sens. W języku Ruby, jak robisz include SomeModule, to metody zdefiniowane bezpośrednio w tym module powinny stać się metodami instancji naszej klasy. Tyle w temacie.

No okej, to się dzieje samo, InstanceMethods nie jest do tego potrzebne. Ale robienie takie zmiany teraz jaki ma sens? Chyba tylko zniechęcić (czyt. przedłużyć czas zanim się na niego zdecydują) ludzi do upgradu. Zmieniaj teraz swoje wszystkie appki, gemy. Proś twórców/wysyłaj pull requesty o zmianę. Moim zdaniem bez sensu.

Poza tym w większych modułach to pozwalało szybciej zorientować się w kodzie.

Pozwolę sobie zauważyć, że core team railsów raczej nigdy zastanawiał się czy wprowadzić ulepszenia w kontekście trudności jeżeli chodzi o upgrade. A jeżeli chodzi o tą zmianę, to przecież to jest banalne do zrobienia i nie wpływa w ogóle na działanie aplikacji. Ok, będziesz musiał przez jakiś czas zobaczyć trochę warningów, ale co z tego? Ja wolę takie rozwiązanie niż trzymanie jakiegoś API bez końca tylko dlatego, że będzie trzeba coś zmienić w kodzie pluginów i aplikacji.

Ja nie jestem za trzymaniem jakichś dirty hacków tylko i wyłącznie dla kompatybilności wstecz. Ale tutaj to żaden hack, jedna linijka która nikomu nie szkodzi :wink:

Do teraz można było sobie trzymać metody instancji albo bezpośrednio w module albo w InstanceMethods - jak komu wygodniej. Toż to nie python i There’s only one way to do this :smiley:

Tak jak mówiłem - InstanceMethods przydaje się przy większych modułach, gdzie masz więcej niż kilka metod + pare linijek dokumentacji do każdej z nich itd. Chciałeś tylko ClassMethods to zwijałeś sobie w edytorze InstanceMethods i jazda :slight_smile: Teraz sobie nic nie zwiniesz a jeszcze ci appka rzuca wstrętnymi warningami. A warningi na dodatek są z d*py bo jeżeli w module inkludujesz moduł, a ten moduł jeszcze coś inkluduje itd. to warning pokaże Ci tylko klasę w której został zainkludowany ten pierwszy :confused:

Hahaha, argument przeciwko zmianie w bibliotece “bo mi wcześniej edytor potrafił ładniej foldować”. Dude, przegrałeś flejma.

Czterdziesty drugi.

Po pierwsze primo, żaden tam flejm :wink:

Po drugie primo - ja tylko zauważam, że chłopaki mogli by się zdecydować. Pierwsza wersja AS::Concern na GitHubie nie inkluduje InstanceMethods. Potem zmienili zdanie i zaczęli inkludować, a teraz po 2.5 roku (jak już wszyscy używają sobie spokojnie wersji z InstanceMethods) nagle ich olśniło, że przecież to się i tak przecież dzieje samo więc po co ta dodatkowa, straszna, jedna linijka :smiley: Moim zdaniem to nic nie wnosząca zmiana dla samej zmiany :smiley:

Poza tym znowu wyciągasz jedno zdanie z całej wypowiedzi i tylko jego się uczepiasz :wink:

Przecież merytoryczną część dyskusji już wyczerpaliście z Drogomirem, więc można się pobawić :smiley:

Damn you, Tomash, jak Ty to robisz, że po tylu latach, po tylu postach ludzie dalej dają się strollować przez Ciebie ?:smiley: