NilClass, TrueClass and FalseClass having one instance each, namely nil, true and false, which are constants, what is the purpose of having these classes? Why cannot they be instances of the Object class, and all the relevant methods be simply defined as singleton methods on nil, true and false? A related question is, why are these not defined as constants?
NilClass,TrueClass和FalseClass各有一个实例,即nil,true和false,它们是常量,拥有这些类的目的是什么?为什么它们不能成为Object类的实例,所有相关的方法都被简单地定义为nil,true和false的单例方法?一个相关的问题是,为什么这些没有被定义为常数?
2 个解决方案
#1
11
It keeps with the idea that "everything is an object" and "objects are specialized by the classes they are instances of".
它始终坚持“一切都是对象”和“对象由它们所属的类来专门化”的想法。
nil, true, and false are all objects (and are thus instantiations of a class with methods). The imposition that they are 1) the sole inhabitants of the respective type and are 2) immutable objects allows for implementation optimizations -- and really, isn't one nil enough?
nil,true和false都是对象(因此是具有方法的类的实例化)。他们是1)相应类型的唯一居民并且2)不可变对象的强制允许实现优化 - 并且实际上,不是一个零吗?
A helpful error message without specialization for the values: x.class "just works".
一个有用的错误消息,没有值的特化:x.class“只是工作”。
> > nil.foo
> => #<NoMethodError: undefined method `foo' for nil:NilClass>
I am glad it said NilClass :-)
我很高兴它说NilClass :-)
This class-instance approach also makes re-opening NilClass -- for better or worse -- as easy and consistent with how it might be done for other types.
这种类 - 实例方法也使得重新打开NilClass - 无论好坏 - 与其他类型的方式一样容易和一致。
At least as of Ruby 1.9.2 it is not possible to re-assign true, false or nil (Python 2.x allowed re-assignment of True/False, but does not in Python 3.x). Note that because true/false/nil are not constants they can be optimized into the AST -- or whatever the implementation uses -- as "literal values" without a constant look-up.
至少从Ruby 1.9.2开始,不可能重新分配true,false或nil(Python 2.x允许重新分配True / False,但不在Python 3.x中)。请注意,因为true / false / nil不是常量,所以它们可以优化为AST - 或者无论实现使用什么 - 作为“文字值”而不进行常量查找。
> > VERSION
> => "1.9.2"
> > true = false
> => #<SyntaxError: Can't change the value of true>
> > [].each {|true|}
> => #<SyntaxError: Can't change the value of true>
Happy coding.
#2
1
Ruby takes the approach of "just take an object and add some singleton methods to it" some of the time:
Ruby采用“只是取一个对象并在某些时候添加一些单例方法”的方法:
C:\Documents and Settings\a.grimm>irb
irb(main):001:0> self.methods - Object.new.methods
gives
[:public, :private, :include, :context, :conf, :irb_quit, :exit, :quit, :irb_print_working_workspace, :irb_cwws, :irb_pwws, :cwws, :pwws, :irb_current_working_binding, :irb_print_working_binding, :irb_cwb, :irb_pwb, :irb_chws, :irb_cws, :chws, :cws, :irb_change_binding, :irb_cb, :cb, :workspaces, :irb_bindings, :bindings, :irb_pushws, :pushws, :irb_push_binding, :irb_pushb, :pushb, :irb_popws, :popws, :irb_pop_binding, :irb_popb, :popb, :source, :jobs, :fg, :kill, :help, :irb_exit, :irb_context, :install_alias_method, :irb_current_working_workspace, :irb_change_workspace, :irb_workspaces, :irb_push_workspace, :irb_pop_workspace, :irb_load, :irb_require, :irb_source, :irb, :irb_jobs, :irb_fg, :irb_kill, :irb_help]
[:public,:private,:include,:context,:conf,:irb_quit,:exit,:quit,:irb_print_working_workspace,:irb_cwws,:irb_pwws,:cwws,:pwws,:irb_current_working_binding,:irb_print_working_binding,:irb_cwb,: irb_pwb,:irb_chws,:irb_cws,:chws,:cws,:irb_change_binding,:irb_cb,:cb,:workspaces,:irb_bindings,:bindings,:irb_pushws,:pushws,:irb_push_binding,:irb_pushb,:pushb,:irb_popws, :popws,:irb_pop_binding,:irb_popb,:popb,:source,:jobs,:fg,:kill,:help,:irb_exit,:irb_context,:install_alias_method,:irb_current_working_workspace,:irb_change_workspace,:irb_workspaces,:irb_push_workspace,:irb_pop_workspace ,:irb_load,:irb_require,:irb_source,:irb,:irb_jobs,:irb_fg,:irb_kill,:irb_help]
I don't know why they don't do this approach with true, false or nil. Maybe because people need to understand these objects (as per pst's answer), whereas people don't need to understand the "main" (?) object.
我不知道他们为什么不用true,false或nil做这种方法。也许是因为人们需要理解这些对象(按照pst的答案),而人们不需要理解“主要”(?)对象。
#1
11
It keeps with the idea that "everything is an object" and "objects are specialized by the classes they are instances of".
它始终坚持“一切都是对象”和“对象由它们所属的类来专门化”的想法。
nil, true, and false are all objects (and are thus instantiations of a class with methods). The imposition that they are 1) the sole inhabitants of the respective type and are 2) immutable objects allows for implementation optimizations -- and really, isn't one nil enough?
nil,true和false都是对象(因此是具有方法的类的实例化)。他们是1)相应类型的唯一居民并且2)不可变对象的强制允许实现优化 - 并且实际上,不是一个零吗?
A helpful error message without specialization for the values: x.class "just works".
一个有用的错误消息,没有值的特化:x.class“只是工作”。
> > nil.foo
> => #<NoMethodError: undefined method `foo' for nil:NilClass>
I am glad it said NilClass :-)
我很高兴它说NilClass :-)
This class-instance approach also makes re-opening NilClass -- for better or worse -- as easy and consistent with how it might be done for other types.
这种类 - 实例方法也使得重新打开NilClass - 无论好坏 - 与其他类型的方式一样容易和一致。
At least as of Ruby 1.9.2 it is not possible to re-assign true, false or nil (Python 2.x allowed re-assignment of True/False, but does not in Python 3.x). Note that because true/false/nil are not constants they can be optimized into the AST -- or whatever the implementation uses -- as "literal values" without a constant look-up.
至少从Ruby 1.9.2开始,不可能重新分配true,false或nil(Python 2.x允许重新分配True / False,但不在Python 3.x中)。请注意,因为true / false / nil不是常量,所以它们可以优化为AST - 或者无论实现使用什么 - 作为“文字值”而不进行常量查找。
> > VERSION
> => "1.9.2"
> > true = false
> => #<SyntaxError: Can't change the value of true>
> > [].each {|true|}
> => #<SyntaxError: Can't change the value of true>
Happy coding.
#2
1
Ruby takes the approach of "just take an object and add some singleton methods to it" some of the time:
Ruby采用“只是取一个对象并在某些时候添加一些单例方法”的方法:
C:\Documents and Settings\a.grimm>irb
irb(main):001:0> self.methods - Object.new.methods
gives
[:public, :private, :include, :context, :conf, :irb_quit, :exit, :quit, :irb_print_working_workspace, :irb_cwws, :irb_pwws, :cwws, :pwws, :irb_current_working_binding, :irb_print_working_binding, :irb_cwb, :irb_pwb, :irb_chws, :irb_cws, :chws, :cws, :irb_change_binding, :irb_cb, :cb, :workspaces, :irb_bindings, :bindings, :irb_pushws, :pushws, :irb_push_binding, :irb_pushb, :pushb, :irb_popws, :popws, :irb_pop_binding, :irb_popb, :popb, :source, :jobs, :fg, :kill, :help, :irb_exit, :irb_context, :install_alias_method, :irb_current_working_workspace, :irb_change_workspace, :irb_workspaces, :irb_push_workspace, :irb_pop_workspace, :irb_load, :irb_require, :irb_source, :irb, :irb_jobs, :irb_fg, :irb_kill, :irb_help]
[:public,:private,:include,:context,:conf,:irb_quit,:exit,:quit,:irb_print_working_workspace,:irb_cwws,:irb_pwws,:cwws,:pwws,:irb_current_working_binding,:irb_print_working_binding,:irb_cwb,: irb_pwb,:irb_chws,:irb_cws,:chws,:cws,:irb_change_binding,:irb_cb,:cb,:workspaces,:irb_bindings,:bindings,:irb_pushws,:pushws,:irb_push_binding,:irb_pushb,:pushb,:irb_popws, :popws,:irb_pop_binding,:irb_popb,:popb,:source,:jobs,:fg,:kill,:help,:irb_exit,:irb_context,:install_alias_method,:irb_current_working_workspace,:irb_change_workspace,:irb_workspaces,:irb_push_workspace,:irb_pop_workspace ,:irb_load,:irb_require,:irb_source,:irb,:irb_jobs,:irb_fg,:irb_kill,:irb_help]
I don't know why they don't do this approach with true, false or nil. Maybe because people need to understand these objects (as per pst's answer), whereas people don't need to understand the "main" (?) object.
我不知道他们为什么不用true,false或nil做这种方法。也许是因为人们需要理解这些对象(按照pst的答案),而人们不需要理解“主要”(?)对象。