@Mr. Andrews: That's a good idea, but, well, this isn't something I'd like to do every time for all the classes that give me trouble. But it'll be useful for now; thank you. :)
@Mr. Sasse: > "only"! I didn't know you could do that at all. In ruby a lowercase > name is just a method, but it may have nothing to do with any particular > class. Actually, what you're referring to here is tangent to the issue I'm talking about, but I'll explain it. This is a Shoes-specific thing: I found out about it in Mr. Why's post about custom widgets (http://hackety.org/2008/06/12/martinDemellosGooeyChallenge.html). When Shoes can't find a method, it apparently looks for a class with the same name (case insensitive); if it finds one, it initializes it with the method's arguments. For instance. Mr. Why created a BorderButton class, and he initialized an BorderButton object with the method borderbutton. (Mr. Why probably did this to be consistent with methods like button() and para(), which initialize classes like Button and Para.) Now, probably for speed purposes, he's apparently limited it to Widget subclasses only...but I may be mistaken. > > I've looked at that pretty carefully and they look the same to me. > The difference is in the OKButton class's superclass. One is Button (doesn't work now); the other is Widget. I correspondingly called either super() or button() in the class's initialize() method. > How exactly did you do that? If your program was running, then the > initial shoes dialogue goes away, so you just have the interface you > wrote. I'm not sure what the second sentence means, but that's probably my ignorance. :) I think I can guess at your question (forgive me if you already know the next part). In Mac OS X, Shoes runs as a single Application, which opens Ruby and Shy files. A single running OS X application hosts many Shoes programs. However, it seems like as long as I don't actually quit from the Shoes application, programs' classes or something are saved—I'm guessing this because quitting the Shoes application and relaunching it, then opening my own program in it, gets rid of the superclass clash error and thus seems to "reset" whatever it saved. > Do you have the exact text of the error? Here it is (I'll have to type this out—I wish it were possible to select text in a Shoes program. :( )... Error in /Applications/Shoes/..blah, blah.../lib/shoes.rb line 359 superclass mismatch for class OKButton I fear that I'm poorly explaining this problem. Here's the deal: in Mac OS X, Shoes runs as a single application. I keep it open all the time when I program so that when I run my program, I can just switch to it, instead of relaunching it and bringing up the console window every time. However, when I edited a program by changing a class's superclass, and then ran it in Shoes, Shoes could not compile it. It raised the error you see above. This made me suspect that Shoes keeps some sort of data as long as it's open to speed up future programs. However, it raises the possibility of very surprising behavior to happen in the future, like this error today. > If a ruby program reads files with the same classes in, the classes > get extended. Yes, this can lead to problems. Yes, and if this can lead to problems, then documentation is needed on how this persistence works in Shoes. I appeal to Mr. Why: could you explain why this behavior is happening? Thank you everyone for replying, and sincerely, Joshua Choi Postscript: Here is how to (hopefully) duplicate this on your machine. Make sure you are using Mac OS X: I don't know if the same behavior happens on Linux or Windows...but I suspect that it won't, because the latter two manage applications on a window basis, not a application basis. Run the following: class A end class B end class C < A end Shoes.app do para 'Testing' end Launch Shoes. Open the file. Close the file. Do not quit Shoes. Edit the file: change the superclass of C to B: class C < B end Open the file. Shoes cannot open the file, and the Terminal pops up and shows the error. Hopefully this is duplicable.
