This would probably be possible in Python with threads, where you halt the thread with the breakpoint, and spawn another thread to take over the response. The scalability issue isn't really a problem in this case (as it would be if you were using continuations for something other than debugging, as in Borges). Certainly easier to implement with continuations, though. As an aside, I've never actually liked breakpoints...
Oh, ruby-breakpoint uses continuations for implementing Binding.of_caller. This is necessary because a call to breakpoint() should spawn an IRB shell at the right point with the caller's context. It is quite involved and a very specific situation, but it shows that continuations can be useful even outside of traditional flow control. If you never actually liked breakpoints you should IMHO still have a look at this at http://ruby-breakpoint.rubyforge.org/ -- it is quite different to traditional stop and step debugging.
Of course, now that I look more closely at Ruby blocks, they don't act like I thought they did; they aren't really like Smalltalk blocks (unless you use lambda).
I accuse you of class-think! ;) I have lots of file-like objects that aren't files. A read_chunks_of(file) function will work great on any file-like object; File#read_chunks_of() will only work on actual File (or subclass) objects. Class-think breaks duck typing. Extending classes is also hard to keep track of; one of the most important aspects of Python namespaces is how reversable they are, so you can track where stuff comes from.
Oh, sorry. This was my error. I should have said File.read_chunks_of which is similar to File.read -- in that case there is no trouble with reusability. You still raise a valid point, though, and perhaps MixIns should be used even more in Ruby when adding new functionality.
For instance, lets say you are making a CMS, and you want to add all sorts of methods to files that deal with workflow, parsing, etc -- you are using files as one of many basic content types. You could simply add those CMS content methods to the file class. But with adaptation you would make a wrapper that has the methods you want (and only the methods you want), and register the wrapper as handling things with the file interface. That means it will work with anything with the file interface (not just the file class), and other people can make other wrappers for other kinds of objects. And the whole thing is introspectable, and implies semantics in addition to signatures.
This way you don't get collisions, you get objects that really are what you want them to be (CMS content objects, not files posing as CMS content objects), but you also can use them as their "real" type (if you make sure to adapt them back to IFile).
Yup, this is similar to ruby-contract -- but still, I think that wrappers are not always the best solution to problems. If a good implementation of selector namespaces can be found I think it is besser for solving this specific problem. (Even though it has not been a serious problem so far. -- I guess it is part of the Ruby mindset that being tolerant is usually a good idea, even if it might mean that you can step onto others toes.)
In practice most Python programmers get by just fine when they do stuff that risks name collision. Some people say it's just because the applications are small and reuse not that common; and it's people with an eye to big systems (like Zope 3 people) that are pushing for more isolation. I'm still not sure if it's easier just to deal with problems when they occur, instead of trying to avoid all possible conflicts. Especially in an open-source ecosystem -- when all code is open to change, and there is no "my code" and "not my code" -- I think problem-avoidance isn't as important as intelligent and cooperative problem-solving. And of course we both have the option to monkey patch (fix the code in-process, instead of on-disk).# Ian Bicking