Ale kombinujecie jak koń pod górkę. Tworzenie wirtualnego atrybutu jako sposób zwracania wyniku działania metody. No takiego obejścia na około problemu którego nie ma to jeszcze nigdy nie widziałem.
chyba chodziło o to 
Ah. Nie mówię, że inny sposób, w który bym to rozwiązał jest lepszy (od tak kategorycznych poglądów raczej zwykle zdecydowanie się uciekam, w programowaniu trudno zwykle coś jednoznacznie nazwać lepsze lub gorsze, raczej ma swoje zalety i wady), jeno bardziej bliższy pewnym koncepcjom które są za to bliskie mi. Rozwiązanie to tylko sobie wyobrażam, bo za mało znam dziedzinę problemu bym miał jego pełen zarys. Od razu mówię, że Advertiser to jest dla mnie rodzaj jakiegoś podmiotu, usera, tak wnioskuję po fakcie, że trzeba go zweryfikować gdy nie znany. Wyobrażam więc całe rozwiązanie w ten sposób, że przepuściłbym akcję przez current_usera, który w zależności od tego jakiej klasy byłby obiektem definiowałby nieco inaczej zachowanie. Powiedzmy, że jest Advertiser i Guest.
[code=ruby]class Advertiser
def create_ad!(ad_attributes)
ad = Ad.new(ad_attributes)
ad.advertiser = self
ad.save!
return ad, :awaiting_verification
end
end
class Guest
def create_ad!(ad_attributes)
ad = Ad.new(ad_attributes)
ad.save!
AdMailer.ad_token(ad).deliver
return ad, :awaiting_email_confirmation
end
end
class ApplicationControoler
def current_user
# Advertiser albo gues
end
end
class AdsController
def create
ad, state = current_user.create_ad!(params[:ad])
flash[:notice] = state
redirect …
rescue ValidationError => e
@ad = e.record
render :new
end
end[/code]
Zastrzegam, że mogłem sobie wszystko źle wyobrazić i zrozumieć. Moim zdaniem ten state mógłby być przy użyciu maszynie stanów prawdziwym polem (ale już nie wierzę w użycie go jako wirtualny atrybut).