From: "Marcel Molina Jr." Date: 2007-06-29T07:38:22+09:00 Subject: Re: Proc initialize method not called under certain circumstances On Fri, Jun 29, 2007 at 06:54:49AM +0900, MenTaLguY wrote: > On Fri, 29 Jun 2007 06:24:48 +0900, "John Lam (CLR)" wrote: > > So, is it correct to assume that for language constructs that create > > built-in types like Range, Array, Hash etc that user-defined initialize > > methods are never called? > > Yes. Generally, Class.new calls .allocate and then #initialize on the returned > object, but there's no guarantee that either of those methods will be used if > the object is created a different way and/or if .new is overridden for a particular > class. It's not just a matter of "no guarantee", it straight up does not happen much in a similar way as what John is asking about Proc.new vs lambda vs a method with a block argument. >> class Class; def initialize(*args, &block) super; puts 'hello' end end => nil >> Class.new hello >> class Foo; end => nil In eval.c, the NODE_CLASS case eventually calls rb_define_class_id which itself calls rb_class_new which in turn calls rb_class_boot which creates the RClass struct and sets its members. rb_class_new_instance is never called though, which is what new is mapped to for rb_cClass. From my understanding, that's the reason there is that behavior for class creation. I'd assume something similar is true for Proc's. Really though, I think John is wondering if this is intentional and if so why. I'm interested in the answer to that too :) marcel -- Marcel Molina Jr.