A to akurat jest całkiem niegłupie ponieważ prostsze i wymagające mniej teorii niż .each, patrz też:
To tak jak z niepisaniem testów i dokumentacji: możesz sobie robić cokolwiek jeśli jesteś pewien że do końca życia projektu pozostaniesz jedyną osobą z tym kodem pracującą.
z batsavo akurat chodziło mi o konwencje, bo autor tematu napisał, że takowej w Rubym nie ma.
No nie no… Wymaganie znajomości multiple-inheritance, Message passing and dispatch, Blocks passed to function calls itd do użycia #each to tak, jakbyś od osoby uczącej się Railsów oczekiwał znajomości tego, co siedzi pod ActiveRecord::Relation, albo ActiveRecord::QueryMethods::WhereChain.
Możesz redukować do absurdu ile tylko chcesz (i używając fałszywej analogii). Ale musisz przyznać że trzeba te kwestie omówić chociaż z grubsza żeby wyjaśnić, skąd się bierze .each i dlaczego działa tak jak działa.
Ale przecież w tym kursie zaraz po tym jest #each bez (prawdopodobnie, bo nie kupiłem) wyjaśnienia 90% punktów, które podane są we wpisie z Twojego linku.
irb(main):014:0>[quote=“radarek, post:18, topic:7452”]
Tworzenie plików
(o wstawianie spacji po między nazwę metody a “()” )
Dlaczego nie może? Nie jest oczywiście to dobrą praktyką, ale nie potrafię odtworzyć sytuacji, że “nie zadziała”.
[/quote]
irb(main):012:0> plik=File.new(“test.txt”, “r”)
=> #<File:test.txt>
irb(main):013:0> plik=File.new (“test.txt”,“r”)
SyntaxError: (irb):13: syntax error, unexpected ‘,’, expecting ‘)’
plik=File.new (“test.txt”,“r”)
^
(irb):13: syntax error, unexpected ‘)’, expecting end-of-input
from C:/Ruby200-x64/bin/irb:12:in `’
Ja testowałem z
plik=File.new ("test.txt")
i to działa. Ale faktycznie dla 2 parametrów już nie.
Bo parser to potraktowal jakbys mu przekazal argumenty bez nawiasow gdzie argumentem jest jakies expression w nawiasie
Faktycznie. Z tym, że zdziwiony jestem trochę bo wydawało mi się, że ruby w przypadku foo ("bar")
zarzuci jakimś warningiem ale tak nie robi (miałem wrażenie, że dawniej tak właśnie było).
Podsumowując:
- przykłady sprawdzaliśmy wielokrotnie,
- nawet Kolega się czegoś nauczył przy okazji publikacji naszego kursu
Zupełnie mnie ten argument nie przekonuje. Codziennie uczę się nowych rzeczy, zarówno od bardziej jak i mniej doświadczonych programistów. Zresztą chyba najwięcej uczę się na swoich i cudzych błędach ;-).
Tak z ciekawości. Czy przed nakręceniem tego kursu była przygotowana transkrypcja, którą ktoś sprawdził pod kątem merytorycznym, czy też osoba nagrywająca szła na żywioł? Mam wrażenie, że nikt nie sprawdzał części merytorycznej materiału i teraz macie problem bo raczej nie wierzę, że nagracie ponownie materiał uwzględniając nasze uwagi (a jak widać wyżej ja miałem ich kilka po oglądnięciu 3 krótkich części).
Ja proponuję, by Kolega napierw przetestował, a później pisał, jedna uwaga była już nie trafiona a teraz kolejna:
irb(main):001:0> puts “tomek”.Upcase
NoMethodError: undefined method Upcase' for "tomek":String from (irb):1 from C:/Ruby200-x64/bin/irb:12:in
’
irb(main):002:0> puts “tomek”.upcase
TOMEK
=> nil
Na który zarzut to ma być odpowiedź? Na ten, że nazwy metod mogą się również zaczynać od wielkich liter? Bo jeśli tak, to to jest epic fail - to, że metoda String.Upcase
nie istnieje nie znaczy, że nie można definiować metod zaczynających się od wielkiej litery.
Rozmawiamy o metodzie .upcase, czy definiowanej metodzie .Metoda?
Jeszcze chwila i dowiem się, że Zmienna to zmienna?
Dlatego właśnie pytałem, na który zarzut to miała być odpowiedź. Więc na który?
Panie Tomaszu, proszę nie zmuszać mnie do oglądnięcia filmu jeszcze raz ;-).
W filmie pt. “Definiowanie i wywoływanie metod” w 1m25s pada stwierdzenie “(…) naszej metodzie musimy nadać jakąś nazwę. Ważna rzecz - nazwa musi być napisana z małej litery”.
I tak jak napisałem - otóż nie musi.
[4] pry(main)> def Foo; puts "foo"; end
=> :Foo
[5] pry(main)> Foo()
foo
=> nil
@radarek Akurat w tym przykładzie nie zgodzę się z Tobą. To, że można zdefiniować metodę z dużej litery nie znaczy, że należy o tym głośno mówić. Wiem, że poprawniej byłoby stwierdzić ‘nazwa powinna być napisana z małej litery’, ale początkujący i tak mają mnóstwo rzeczy do zrozumienia i zapamiętania, tak więc nie sądzę, żeby to robiło dużą różnicę.
To tak, jak na matematyce jest tłuczone przez kilka lat, że nie istnieje pierwiastek z -1, a potem na pierwszych zajęciach na studiach człowiek się dowiaduje, że był okłamywany całe życie. Na początku nie musisz znać liczb zespolonych, żeby radzić sobie dobrze z matematyką.
Widzisz, zahaczasz o bardzo fajny temat. Co powinno a czego nie powinno się mówić osobie, którą wprowadzamy w jakiś temat. Otóż w tym wypadku, moim zdaniem, lepiej byłoby nie poruszać tego tematu i tyle (zakładam, że autor gdzieś wcześniej wyjaśnia słuchaczowi, że ruby ‘zwraca’ uwagę na małe i duże litery wiec przepisując kod z tutoriala powinno się zachować dokładnie taką samą formę).
[quote]
To, że można zdefiniować metodę z dużej litery nie znaczy, że należy o tym głośno mówić.
[/quote
Otóż to. Wystarczy głośno o tym nie mówić.
Natomiast tutaj pada po prostu nieprawdziwe stwierdzenie i uczona osoba jest wprowadzona w błąd.