From transfire at gmail.com Thu Aug 25 13:14:40 2005 From: transfire at gmail.com (TRANS) Date: Thu Aug 25 13:08:05 2005 Subject: [suby-talk] Truly Private Methods Message-ID: <4b6f054f0508251014524bdf9a@mail.gmail.com> Ramifications if private methods were in their own namespace? ( o _ ??? // trans. / \ transfire@gmail.com From calamitas at advalvas.be Thu Aug 25 15:11:44 2005 From: calamitas at advalvas.be (calamitas@advalvas.be) Date: Thu Aug 25 15:05:36 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: <4b6f054f0508251014524bdf9a@mail.gmail.com> References: <4b6f054f0508251014524bdf9a@mail.gmail.com> Message-ID: > Ramifications if private methods were in their own namespace? I've been thinking about this exact idea too. I think it would be nice. For the moment Module#private and alike control accessibility, not visibility. IMO the latter makes more sense. When you make a method private as things are now, a working application should not call the method. Unless of course by using send, in which case it does not matter whether the method is private or not. OTOH, the names of private methods can still cause name conflicts when subclassing or being subclassed. So it is simply not possible to completely hide one's own utility methods. Some people argue you shouldn't do this because all it does is annoy the people who want to override your methods. I think the use of namespaces here is a nice trade-off. Namespaces give you the power to select what methods you want to see. This means you can put the private methods in a separate namespace, but still if a brave someone really wants access these internals, it's simply a matter of asking to see them. (This is all provided that namespaces work the way I expect them to.) Peter From calamitas at advalvas.be Fri Aug 26 06:28:14 2005 From: calamitas at advalvas.be (calamitas@advalvas.be) Date: Fri Aug 26 06:22:32 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: References: <4b6f054f0508251014524bdf9a@mail.gmail.com> Message-ID: >> Ramifications if private methods were in their own namespace? Actually this extends nicely to protected methods as well. They are put in their own namespace too. The private namespace is by default included only in the namespace of the class itself, the protected namespace however is also included in the namespace of the subclasses. I think you're onto something good here. Provided namespaces become a reality in Ruby some day of course. Peter From transfire at gmail.com Fri Aug 26 06:44:10 2005 From: transfire at gmail.com (TRANS) Date: Fri Aug 26 06:37:33 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: References: <4b6f054f0508251014524bdf9a@mail.gmail.com> Message-ID: <4b6f054f0508260344738e7704@mail.gmail.com> On 8/25/05, calamitas@advalvas.be wrote: > > Ramifications if private methods were in their own namespace? > > I've been thinking about this exact idea too. I think it would be nice. > For the moment Module#private and alike control accessibility, not > visibility. IMO the latter makes more sense. When you make a method > private as things are now, a working application should not call the > method. Unless of course by using send, in which case it does not matter > whether the method is private or not. OTOH, the names of private methods > can still cause name conflicts when subclassing or being subclassed. So it > is simply not possible to completely hide one's own utility methods. Some > people argue you shouldn't do this because all it does is annoy the people > who want to override your methods. I think the use of namespaces here is a > nice trade-off. Namespaces give you the power to select what methods you > want to see. This means you can put the private methods in a separate > namespace, but still if a brave someone really wants access these > internals, it's simply a matter of asking to see them. > > (This is all provided that namespaces work the way I expect them to.) I agree. Yet expand on the last statement. We've talked about namespaces before, and I've touched on how I envision them (at least to the end-user). What's your expectation? Trans From transfire at gmail.com Fri Aug 26 06:57:32 2005 From: transfire at gmail.com (TRANS) Date: Fri Aug 26 06:50:56 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: References: <4b6f054f0508251014524bdf9a@mail.gmail.com> Message-ID: <4b6f054f05082603576022fb11@mail.gmail.com> On 8/26/05, calamitas@advalvas.be wrote: > >> Ramifications if private methods were in their own namespace? > > Actually this extends nicely to protected methods as well. They are put in > their own namespace too. The private namespace is by default included only > in the namespace of the class itself, the protected namespace however is > also included in the namespace of the subclasses. I think you're onto > something good here. Provided namespaces become a reality in Ruby some > day of course. Oh, that is nice. I was wondering how protected would fit into this. So to eleborate a little more. How would this effect calling a method using the 'self.' prefix. At the very least, the private methods arn't avaible via this receiver. Correct? But a more interesting prospect: given the seperate namespaces, is it then possible to have an "overriding" method? In other words: class A public def x ; 'public' ; end private def x ; 'private' ; end public def both x #=> 'private' self.x #=> 'public' end end It seems almost like an inheritance chain. T From calamitas at advalvas.be Fri Aug 26 09:32:40 2005 From: calamitas at advalvas.be (calamitas@advalvas.be) Date: Fri Aug 26 09:26:30 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: <4b6f054f0508260344738e7704@mail.gmail.com> References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f0508260344738e7704@mail.gmail.com> Message-ID: > I agree. Yet expand on the last statement. We've talked about > namespaces before, and I've touched on how I envision them (at least > to the end-user). What's your expectation? Well, a namespace is essentially a collection of methods (although I think things like instance variables and all could go into them too) that can be seen using a particular pair of glasses. Every class's private methods for example could go into a separate namespace, but the instance methods automatically are put on the glasses so they can see them. However glasses stack, so one could put on multiple pairs of glasses and see the combination of what each of these glasses can see. Of course in case methods in different namespaces have the same names, there is precedence (depending on which glasses you put on first). Of course it is also possible to explicitly use a given pair of glasses, even if you were not wearing them already. So more specifically... Every class has three namespaces associated with it. Say you have a class A. Then public methods go in A_ns (or whatever it will be called), private methods in A_private_ns, and protected ones in A_protected_ns. A_ns is available from everywhere automatically, while A_private_ns is only available in class A and A_protected_ns is only available in A and its subclasses. The order of the namespaces in a class is always such that public methods get preferences, then the private and protected ones, and then the public and protected ones from the superclass, and so on. If a method from a specific namespace is wanted, it can just be called with a prefix, say A_protected_ns:meth. And the syntax for puttin on the glasses for a certain namespace would go something like this: namespace(:name_of_namespace) { blahbla } Now I think namespaces allow you to do private/protected in a much cleaner way, but it can actually do much more. Say that you can also alias namespaces. Then A_super_ns could be aliased to super and methods in the super class could directly be called as super:meth. It could even supersede cuts. I mean, using namespaces, it would be easy to slip in a namespace for the cuts. IMO, namespaces defined like this can unify quite a few concepts, and add tremendous power, but still in a controlled way. However, problem seems to be how to efficiently implement all this. Peter From calamitas at advalvas.be Fri Aug 26 09:41:20 2005 From: calamitas at advalvas.be (calamitas@advalvas.be) Date: Fri Aug 26 09:35:32 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: <4b6f054f05082603576022fb11@mail.gmail.com> References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f05082603576022fb11@mail.gmail.com> Message-ID: > Oh, that is nice. I was wondering how protected would fit into this. > > So to eleborate a little more. How would this effect calling a method > using the 'self.' prefix. At the very least, the private methods arn't > avaible via this receiver. Correct? At the moment, but the fact that provate methods can be called with an explicit receiver are IMO a means to an end. It's a way to implement accessibility control, but namespaces would change that. With namespaces, it would be possible to call a private method with an explicit receiver because it uses another mechanism to check visibility. > But a more interesting prospect: > given the seperate namespaces, is it then possible to have an > "overriding" method? In other words: > > class A > public def x ; 'public' ; end > private def x ; 'private' ; end > public def both > x #=> 'private' > self.x #=> 'public' > end > end Well, I would name the namespaces explicitly. So this would be: class A public def x ; 'public' ; end private def x ; 'private' ; end public def both x #=> 'private' public:x #=> 'public' end end Note that the private version needs no specifier as it takes precedence over the public things. Also this assumes the namespace is actually called "private", it could be "A_private_ns" or whatever, but I'm not sure whether these namespace names should be global or not, or can be locally aliased... > It seems almost like an inheritance chain. My thoughts exactly! (See my previous email.) Peter From calamitas at advalvas.be Fri Aug 26 17:04:35 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Fri Aug 26 16:58:27 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f05082603576022fb11@mail.gmail.com> Message-ID: > At the moment, but the fact that provate methods can be called with an This is of course about prIvate methods that can'T be called with an explicit receiver... Peter From transfire at gmail.com Sat Aug 27 17:37:48 2005 From: transfire at gmail.com (TRANS) Date: Sat Aug 27 17:31:10 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f05082603576022fb11@mail.gmail.com> Message-ID: <4b6f054f05082714374698bf3b@mail.gmail.com> So I spent some time giving this serious consideration. It was actually quite frstrating at first. But then it started to come together much better. Your "hint" that these namespace could superced cuts reminded me of the originla motivating principle(s) behind them --the wrap-subclass equivalency and control of the inheritence chain. If namespaces could be cuts then I hankerd that cuts (ie. subclasses) could be namespace (give or take some appropriate control). I cam up with a semi-working example (see attached). The upshot being this heirarchy: # Y is a subclass of X. # x is an instance of X (ie. a public interface) # Likewise y is an instance of Y. # # y # | # V # Y:private -> Y:protected -> Y:public x # | | # V V # X:private -> X:protected -> X:public # # So y can't "see" X:private. # Nor can x "see" X:private or X:protected. The order is reversed from what I think you were saying. In this case private comes first. I tried it the other way at first thinking as you did, but it turned out to be a large part of my confusion. When I finally switched it around it started to fall together. Very interesting! T. -------------- next part -------------- A non-text attachment was scrubbed... Name: priv.rb Type: application/x-extension-rb Size: 1675 bytes Desc: not available Url : http://rubyforge.org/pipermail/suby-talk/attachments/20050827/481ba150/priv-0001.bin From transfire at gmail.com Sun Aug 28 10:02:41 2005 From: transfire at gmail.com (TRANS) Date: Sun Aug 28 09:56:01 2005 Subject: [suby-talk] Why does including "up" have no effect. Message-ID: <4b6f054f0508280702401d14f7@mail.gmail.com> I guess it's not all the suprising but I still wonder what's happening behind the scenes. module Up class Object def t puts "x" end end end include Up o = Object.new o.t The result is an error. When Up is included into the main space how is the conflict between the Object in Up and the main Object resolved. Would it be useful if it worked as if reopening? From calamitas at advalvas.be Sun Aug 28 11:14:12 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Sun Aug 28 11:08:24 2005 Subject: [suby-talk] Why does including "up" have no effect. In-Reply-To: <4b6f054f0508280702401d14f7@mail.gmail.com> References: <4b6f054f0508280702401d14f7@mail.gmail.com> Message-ID: On Sun, 28 Aug 2005, TRANS wrote: > I guess it's not all the suprising but I still wonder what's happening > behind the scenes. > > module Up > class Object > def t > puts "x" > end > end > end > > include Up > o = Object.new > o.t > > The result is an error. When Up is included into the main space how is > the conflict between the Object in Up and the main Object resolved. > Would it be useful if it worked as if reopening? The conflict is resolved in the same way as with methods: def m 1 end module Up def m 2 end end m # => 1 include Up m # => 1 This is something that confused me too when I first started learning Ruby. When including a module, Ruby does not actually merge the list of methods of the module with the list of methods of the class/module it is included in. Instead the module is inserted in the inheritance chain just underneath the class/module it is included in. Though that has its disadvantages, in the end it makes things more uniform as it just reuses an existing concept. And the problems are avoided when used with care (read: when having full control of all classes and thus able to avoid name conflicts completely). So it's just the way modules work in Ruby. Peter From calamitas at advalvas.be Sun Aug 28 11:31:13 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Sun Aug 28 11:25:24 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: <4b6f054f05082714374698bf3b@mail.gmail.com> References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f05082603576022fb11@mail.gmail.com> <4b6f054f05082714374698bf3b@mail.gmail.com> Message-ID: On Sat, 27 Aug 2005, TRANS wrote: > So I spent some time giving this serious consideration. It was > actually quite frstrating at first. But then it started to come > together much better. Your "hint" that these namespace could superced > cuts reminded me of the originla motivating principle(s) behind them > --the wrap-subclass equivalency and control of the inheritence chain. > If namespaces could be cuts then I hankerd that cuts (ie. subclasses) > could be namespace (give or take some appropriate control). I cam up > with a semi-working example (see attached). The upshot being this > heirarchy: Well, cuts are only part of the idea of namespaces. Cuts allow you to control the order in which methods are seen (using subclassing for this was indeed the idea, and as I realized may have been the missing idea to an efficient implementation). The second part of namespaces is that you want different people to see different things. So basically this means that everyone perceives the inheritance chain differently. This is what would make private methods possible, but private methods are a special case of something more general. A private method is just a method in the current class that no one else can see. A more general concept would be a method in any class that can only be seen from the current class. Unless of course an explicit request is made to see them. This would allow to add extra utility methods to core classes, but only your own code can see them. I think that's why Matz wants namespaces. And that's a concept not even cuts can capture. > # Y is a subclass of X. > # x is an instance of X (ie. a public interface) > # Likewise y is an instance of Y. > # > # y > # | > # V > # Y:private -> Y:protected -> Y:public x > # | | > # V V > # X:private -> X:protected -> X:public > # > # So y can't "see" X:private. > # Nor can x "see" X:private or X:protected. > > The order is reversed from what I think you were saying. In this case > private comes first. I tried it the other way at first thinking as you > did, but it turned out to be a large part of my confusion. When I > finally switched it around it started to fall together. You're right, it was afterwards that I realized that private should come first. The reason is that otherwise other people can define methods that take precendence over your private methods, which is dangerous as these methods are private for a reason then. > Very interesting! Yup, thanks for the discussing. I'm seeing things more clearly now myself. I'll see if I can compile something about this on the wiki. Well, not today, my paper's camera-ready version is due on Tuesday, and I've still got a bit of work to do. Peter From transfire at gmail.com Sun Aug 28 12:06:42 2005 From: transfire at gmail.com (TRANS) Date: Sun Aug 28 12:00:03 2005 Subject: [suby-talk] Why does including "up" have no effect. In-Reply-To: References: <4b6f054f0508280702401d14f7@mail.gmail.com> Message-ID: <4b6f054f0508280906787f25f9@mail.gmail.com> On 8/28/05, Peter Vanbroekhoven wrote: > The conflict is resolved in the same way as with methods: > > def m > 1 > end > > module Up > def m > 2 > end > end > > m # => 1 > include Up > m # => 1 > > This is something that confused me too when I first started learning Ruby. > When including a module, Ruby does not actually merge the list of methods > of the module with the list of methods of the class/module it is included > in. Instead the module is inserted in the inheritance chain just > underneath the class/module it is included in. Though that has its > disadvantages, in the end it makes things more uniform as it just reuses > an existing concept. And the problems are avoided when used with care > (read: when having full control of all classes and thus able to avoid name > conflicts completely). > > So it's just the way modules work in Ruby. That's makes sense about the methods. But I guess I still don't see how that bares on namespaces. > Peter > _______________________________________________ > suby-talk mailing list > suby-talk@rubyforge.org > http://rubyforge.org/mailman/listinfo/suby-talk > -- ( o) ??? // trans. / / transfire@gmail.com From calamitas at advalvas.be Sun Aug 28 13:15:50 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Sun Aug 28 13:09:25 2005 Subject: [suby-talk] Why does including "up" have no effect. In-Reply-To: <4b6f054f0508280906787f25f9@mail.gmail.com> References: <4b6f054f0508280702401d14f7@mail.gmail.com> <4b6f054f0508280906787f25f9@mail.gmail.com> Message-ID: > That's makes sense about the methods. But I guess I still don't see > how that bares on namespaces. It's just the same thing. Ruby does not merge both lists of constants, but keeps them separarte and looks for the constant Object first in Object, then in Up. It's the way Ruby combines different namespaces, and that of the class always comes first, then those of included modules. Am I missing something? Because I don't see the problem. I can only repeat the same thing again. But maybe I should explain more in detail... Given your code: module Up class Object def t puts "x" end end end include Up This creates a situation as follows: Object --> Up ^ | | | |Object |Object |_| V Up::Object The horizontal arrow indicates inheritance (inclusion in this case), the vertical arrows indicate constants defined in the class/module, and is labeled with the name of the constant. Note that (on my machine), Object.id == Object::Object.id == 538238608 and Up::Object.id == 538381366, so Object and Up::Object.id are different classes, and including module Up in Object does not change that. So if you do Object.new, Object is looked up in Object, and if not found there in its included modules, which in this case is Up. But because Object::Object exists, that's the one used, i.e., the one without the method t. So the include does have an effect, but you can't see it because Object::Object shadows Up::Object in the inheritance chain. (It goes left to right in the above picture, and so it encounters Object::Object first. I don't quite see what reopening a class has to do with this. It seems that what you would like is that classes Object::Object and Up::Object are really merged and become one and the same class. That would be kind of weird, wouldn't it? Peter From transfire at gmail.com Sun Aug 28 13:56:38 2005 From: transfire at gmail.com (TRANS) Date: Sun Aug 28 13:50:00 2005 Subject: [suby-talk] Why does including "up" have no effect. In-Reply-To: References: <4b6f054f0508280702401d14f7@mail.gmail.com> <4b6f054f0508280906787f25f9@mail.gmail.com> Message-ID: <4b6f054f05082810564e580d49@mail.gmail.com> In 8/28/05, Peter Vanbroekhoven wrote: > > That's makes sense about the methods. But I guess I still don't see > > how that bares on namespaces. > > It's just the same thing. Ruby does not merge both lists of constants, but > keeps them separarte and looks for the constant Object first in Object, > then in Up. It's the way Ruby combines different namespaces, and that of > the class always comes first, then those of included modules. > > Am I missing something? Because I don't see the problem. I can only repeat > the same thing again. But maybe I should explain more in detail... Given > your code: No, my bad. It makes perfect sense now. I don't know what I was thinking of constants as somehow different. > I don't quite see what reopening a class has to do with this. It seems > that what you would like is that classes Object::Object and Up::Object are > really merged and become one and the same class. That would be kind of > weird, wouldn't it? Yes. Albiet there is one use for something like it as a form of selective class-extension --a kind-of alternative to require. I imagine it might be possible to write a pure Ruby method to do it, say. inject Up But I'm not sure it's useful enough fuse with. T. From calamitas at advalvas.be Sun Aug 28 14:17:49 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Sun Aug 28 14:11:26 2005 Subject: [suby-talk] Why does including "up" have no effect. In-Reply-To: <4b6f054f05082810564e580d49@mail.gmail.com> References: <4b6f054f0508280702401d14f7@mail.gmail.com> <4b6f054f0508280906787f25f9@mail.gmail.com> <4b6f054f05082810564e580d49@mail.gmail.com> Message-ID: > No, my bad. It makes perfect sense now. I don't know what I was > thinking of constants as somehow different. It's surprising how consistent Ruby is :-) Well, constants are also looked up in its static scope (e.g., M1::M is accessible from say M1::M2::M3::C with the M1:: prefix), so that's a difference, but inheritance-wise there's no difference. > Yes. Albiet there is one use for something like it as a form of > selective class-extension --a kind-of alternative to require. I > imagine it might be possible to write a pure Ruby method to do it, > say. > > inject Up Well, it would bump into the same old problem that methods can only move down the inheritance hierarchy. I think we should fix that problem for once and for all in Suby. > But I'm not sure it's useful enough fuse with. I've never needed it, so I have no idea either. Peter From transfire at gmail.com Mon Aug 29 10:44:14 2005 From: transfire at gmail.com (TRANS) Date: Mon Aug 29 10:37:32 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f05082603576022fb11@mail.gmail.com> <4b6f054f05082714374698bf3b@mail.gmail.com> Message-ID: <4b6f054f050829074423c6c3c7@mail.gmail.com> BTW interesting subtlety you've demonstrated on ruby-talk related to this. T. From calamitas at advalvas.be Mon Aug 29 12:51:02 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Mon Aug 29 12:45:24 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: <4b6f054f050829074423c6c3c7@mail.gmail.com> References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f05082603576022fb11@mail.gmail.com> <4b6f054f05082714374698bf3b@mail.gmail.com> <4b6f054f050829074423c6c3c7@mail.gmail.com> Message-ID: > BTW interesting subtlety you've demonstrated on ruby-talk related to this. Although it is only part of the story of course. For the moment it is so that a private methods hides a method by the same name in the superclass. So private methods actually do two things: define methods others can't access, and hide methods in the superclass. If private methods were really local methods, this would not happen as others would not see the private method and could call the method in the superclass. Of course the method in the superclass could be hidden manually using remove_method, if necessary, but at least then it is explicit. I think this tiny twist is an interesting one which can reduce bugs because of name conflicts, and it makes both functions of private methods explicit. Peter From transfire at gmail.com Tue Aug 30 11:07:57 2005 From: transfire at gmail.com (TRANS) Date: Tue Aug 30 11:01:18 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f05082603576022fb11@mail.gmail.com> <4b6f054f05082714374698bf3b@mail.gmail.com> <4b6f054f050829074423c6c3c7@mail.gmail.com> Message-ID: <4b6f054f0508300807f6eff01@mail.gmail.com> On 8/29/05, Peter Vanbroekhoven wrote: > > BTW interesting subtlety you've demonstrated on ruby-talk related to this. > > Although it is only part of the story of course. For the moment it is so > that a private methods hides a method by the same name in the superclass. > So private methods actually do two things: define methods others can't > access, and hide methods in the superclass. If private methods were really > local methods, this would not happen as others would not see the private > method and could call the method in the superclass. Of course the method > in the superclass could be hidden manually using remove_method, if > necessary, but at least then it is explicit. I think this tiny twist is an > interesting one which can reduce bugs because of name conflicts, and it > makes both functions of private methods explicit. I'm inclined to agree. Presently one could grab a method (via instance_method or method) remove it and reuse it that way --essentially local methods. But more tricks. I think its pretty clear, real visibility needs to be addressed. I even think in the mean time we dump private/protected/public in Suby all together. What do you think of that? T. P.S. I wish I could help with this more, but at the mometn its a steep learning curve and I have alot going... but I was wondering how it looks for getting a version of Suby out? --like what we had before would do. I know you want to go back to working off the 1.8.x series, so I thought it best to wait for that transition before I startred doing anything on it. T. From calamitas at advalvas.be Tue Aug 30 11:14:19 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Tue Aug 30 11:08:22 2005 Subject: [suby-talk] Truly Private Methods In-Reply-To: <4b6f054f0508300807f6eff01@mail.gmail.com> References: <4b6f054f0508251014524bdf9a@mail.gmail.com> <4b6f054f05082603576022fb11@mail.gmail.com> <4b6f054f05082714374698bf3b@mail.gmail.com> <4b6f054f050829074423c6c3c7@mail.gmail.com> <4b6f054f0508300807f6eff01@mail.gmail.com> Message-ID: On Tue, 30 Aug 2005, TRANS wrote: > I'm inclined to agree. Presently one could grab a method (via > instance_method or method) remove it and reuse it that way > --essentially local methods. But more tricks. > > I think its pretty clear, real visibility needs to be addressed. I > even think in the mean time we dump private/protected/public in Suby > all together. What do you think of that? I'm all for that. IMO private/protected/public is flawed and mostly useless. > P.S. I wish I could help with this more, but at the mometn its a steep > learning curve and I have alot going... but I was wondering how it > looks for getting a version of Suby out? --like what we had before > would do. I know you want to go back to working off the 1.8.x series, > so I thought it best to wait for that transition before I startred > doing anything on it. I'll give it a go tomorrow. This evening, the paper should wriggle its way through some optic fiber cables and alike to Korea, and then I'll have some more time to work on Suby stuff. I'm also thinking of taking a small vacation some time soon, but I'm not sure when that will be exactly. Peter