On 2005-04-12, Martin DeMello <martindemello / yahoo.com> wrote: > I'm a bit confused about lifecycle issues now. What I have at the moment > is this: > > module IRB > > def IRB.start_in_fxirb(im) [snip] > irb = Irb.new(nil, im) [snip] > class << irb.context.workspace.main > def gets [snip] > end > end > end > > end > > and inside the FXIrb class: [snip] Well, this code look fine to me, but of course, just looking at the code is not enough. > As far as I can make out, inside IRB.start_in_fxirb is the only place I > have access to the IRB.conf[:MAIN_CONTEXT] object after it is > initialised to Irb.new, so that I can create the appropriate singleton > method. It might be that IRB.start_in_fxirb is the appropriate place to define the singleton (I'd say so). But what do you mean by "the only place I have access to ..."? IRB.conf[:MAIN_CONTEXT] is a global accessor, it should work everywhere (unless you have somewhere another IRB constant, which I'm sure is not the case, but even then you could access the object as such via TOPLEVEL_BINDING). > Also I looked at the Context and Workspace code, and don't see > why irb.context.workspace.main would create a new reader. (Thanks for > being patient, btw - the IRB code is fairly labyrinthine until one gets > used to it.) Um, what irb is the irb in "irb.context.workspace.main"? It seems that we were speaking about entirely different things here. When I said, "irb.context.workspace.main" creates a new reader, that happened after checking its effect pasted into an irb prompt. There the respective ...main evaluator object's irb method has been called, and that just creates a new reader. Where you use "irb.context.workspace.main", that is after doing "irb = Irb.new(nil, im)", so the object which the "context.workspace.main" method chain has been passed to, is referred to a local, of course that behaves differently from the above. You could as well say "irb = 5" and complain that "irb.context.workspace.main" blows up with a NoMethodError... However, I made a mistake here as well, as "irb" is really ambigouous... eg., within an IRB::Context object it gives you the main object again (although there you could probably do just "workspace.main"). So, both of us should be more careful about being unambiguous when referring to objects and methods somewhere living in irb's realm. * * * What problems do you have with the code posted? What are "lifecycle problems" you refer to? Csaba