2014-11-14 9 views
0

내가 항상 좋은 것으로 생각했던 루비의 특징은 색인/해시 조회의 기본값 인 nil입니다.Ruby/Rails가 중첩 된 색인 생성을 안전하게 만들지 못했던 이유가 있습니까?

[1, 2, 3][42]   # => nil 
{ foo: :bar }[:spam] # => nil 

루비의 디자인 또는 루비 레일의 핵심 확장에에,이 (오히려 NoMethodError: undefined method '[]' for nil:NilClass을 던지는 것보다) 중첩 된 조회에 일을 연장하지 않은 이유, 이유가 있습니까? 예를 들어

: 내, 아마도 니베에서

{ foo: [1, 2, 3] }[:bar][0][:baz] # => nil 
[[[]]][12][1][1]     # => nil 

, 그것은 간단 할 것 이해 등 : 오브젝티브 C와 같은

class NilClass 
    def [](_); end 
end 
+0

try 명령을 보면 원하는대로 작동합니다. – Doon

+0

나는'시도 '하고있다. 중첩 된 조회가 매우 일반적이므로이 케이스가 왜 최적화되지 않았는지 궁금합니다. – mjgpy3

+1

'h [: k1] [: k2]와'nil [: k2]'의 차이점은 무엇입니까? 'NilClass '에 대한 당신의 제안 된 패치는 너무 멀어 편리 성명으로 버그를 숨길 것입니다. –

답변

1

일부 언어, 방법은 nil 객체에 호출을 nil을 반환하면 이러한 종류의 오류가 사라집니다.

레일즈는 항상 메서드 호출이 실패하는 "whiny nil"을 갖는 경로를 사용했습니다. 이것은 예상 된 행동이되었다.

당신이 당신의 NilClass을 패치 할 것인지 여부를

는 완전히 수행

def NilClass 
    def method_missing(*args) 
    # Do nothing, return nil 
    end 
end 

당신은 오류를 억제 config/initializers이를 추가 할 수 있지만, 경고, 이것은 합법적 인 문제를 숨기고 응용 프로그램이 예상치 못한 방법으로 수행 할 수 있습니다 . 예를 들어. nil.id은 실제로 값을 반환합니다.