From: Austin Ziegler Date: 2006-06-04T23:06:37+09:00 Subject: Re: Another Look at SELECTOR NAMESPACES On 6/3/06, transfire@gmail.com wrote: > Austin Ziegler wrote: >> It isn't mine, either. However, you presented this as an either-or >> proposition, which this most certainly is not. > Not really I just stated my opinion: I just think Ruby should embace it > with a more wholistic solution or back off. JMO. Sorry, but that's an either-or proposition, and it's a false dichotomy. I, for one, am mostly happy with the state of Ruby as it is now. >> I have serious doubts about the utility of selector namespaces (just >> as I have serious doubts about the utility of namespace "renaming" as >> some people seem to be asking for recently because of bad naming >> decisions by yet other developers). I think that the whole desire for >> a feature like "require_wrap" is foolish. >> That said, I see some value, given Ruby's open classes, in having the >> ability to have multiple methods named the same thing but with a >> distinguishing namespace. I think that there's too many unanswered >> questions to wholeheartedly support them, but they may prove useful. >> (For example, when is one defining a method in a namespace vs. >> overriding a method?) >> What I am absolutely certain about is that dynamic resolution of >> selector namespaces is a disaster waiting to happen. I would almost >> rather see Ruby adopt static typing than see dynamic resolution of >> selector namespaces and/or the modification of literal resolution based >> on such dynamic resolution. Because when you do *that*, you can no >> longer trust even the most basic syntactical rules of Ruby and what you >> have is less Ruby than Ruby with static typing would be. > You're really overstating the issue. When you require any lib you're > putting trust into it's functionality. It's not magical, you're > specifically asking for certain behavior. Why do you feel parts of the > core system are sacred? Isn't that more-or-less the way of non-agile > languages? In Ruby we CAN extend the core --we DO extend the core. > Being well aware of this, we also know of some of the limitations that > make it difficult to resuse those extensioins. The idea of selector > namespaces would allow us to do that. If its a bad idea, as you say, > then the bad idea must come from the ability itself. I think you're deliberately misunderstanding. I am explicitly objecting to two bad ideas that you have suggested here: the dynamic resolution of selector namespaces and the inclusion of core syntax into said dynamic resolution. Allowing the override of {}, [], and "" literal creators (among others) would be changing certain fundamental behaviours that we should be able to depend on *no matter what*. I'm not convinced that selector namespaces are a good idea (and I've told Matz as much), but I *am* convinced that the use of (method-)selector namespaces must be explicit and *separate* from class/module namespace resolution. >> I *will* admit that I view most of the suggestions that you, >> personally, make with a great deal more suspicion because I think >> that you ask for things that are ten times more "clever" than they >> would ever be useful. Most of the things that you've proposed that I >> have opposed fall into the category of YAGNI, too. (I also take issue >> with some of your syntactical direction, which I think reduces >> readability and understandability of code.) > First of all, Selector Namespace is not my idea. Matz has talked about > it himself. I was just sharing an interesting proximity to it that can > be achieved in current code. That's it. Um. No, you were also complaining that literal constructors aren't overridable. > Why do you act like the "suggestions" I make are somehow like > legislation being brought to the floor? I mean really! Why do I always > get this crap? Is it becuase I'm the only peson around here that's > willing to explore a loose idea just to see where it goes? I guess you > and your ilk are just too afraid of looking stupid. So you make > yourself look smart by trashing the ideas of others. Is that it? No, you're not the only person who is willing to explore a loose idea. You are, however, one of the few people who will pick up that idea and run with it to your own ends and purposes no matter how little utility would be added and you tend to do so without thinking about the consequences of such a direction or if there is perhaps something better that can be done. I will *freely* admit that I am more conservative about the directions that Ruby should take, but if you look over the last couple of years of your proposals, there have been a few which I have supported because they are good proposals. Other times? We get your ill-informed rants about the quality of RubyGems ([ruby-talk:158548]), your hare-brained "namespaced" load paths ([ruby-core:06001]), your use of punctuation in filenames and pretending that it's a general problem (various places, including [ruby-core:05988]), and I'm sure a few other things that aren't in my quick search of my gmail archive of the Ruby mailing lists. In one of my posts, I said: You're trying to solve a human engineering problem -- namely your problem -- with a computer engineering solution. It's the wrong solution. I still think that's true of most of the solutions that you end up proposing in your "picking up of loose ideas". I think that this is definitely a case of overengineering and underthinking. > No? Well I call Bullshit with the last paraenthecial comment of your > paragraph as case-in-point. You've done this many times now Austin. You > make a negative comment about me that has no contextal support, so > essentially no meaning --it's just there to slander me. In this case > you say you have an issue with my "syntatical direction" What the hell > is that supposed to mean? You spout off these pataitudes and you never > bother to give a single example to back them up. Consider it that I don't feel like digging unnecessarily. You, at least, should know what you've proposed and what I've opposed. Let's just see one: require 'nano:classes/string' require 'nano:classes/string/empty?' In what way is either of those not a trainwreck? (I really don't want to get into the discussion on that, though; they aren't problems that most people would ever encounter because they wouldn't paint themselves into a corner that required it.) [...] >> (2) The fact that "String.new" is being used is an indication that >> something is different. > You have an amazing ability to generailize. No doubt you can tell > Time.new from Time.new as well. Time doesn't have a literal constructor. String does. Unless I've misread completely, in which case I apologise, you've said specifically that dynamic resolution of selector namespaces including literal constructors would be desirable. >> (3) There's no way that the alteration of basic syntactical rules could >> *possibly* be easier to understand. > Er. Easier to undersand than _not telling anyone about the alteration > of basic syntactical rules_, which can easily happen today and is the > crux of this particular point that you somehow manged to utterly miss > --and I really have to wonder, perhaps out of spite b/c I know you are > not dull. But not easier than not altering them in the first place. Which is *precisely* what I'm advocating and what Ruby does. I'm not talking about constant/scope resolution here -- that's reasonably well-defined but getting much better after with Ruby 2.0. I'm talking specifically about the proposal you made for dynamic selector namespace resolution (bad idea) and for inclusion of literal constructors in that (worse idea). >> Far better to work *with* other people than around them, if at all >> possible. > There's an idea. Perhaps you can think about that and instead of > critisizing my techne without substantiation, you could actually offer > constructive suggestions on how I might improve it. I would greatly > appreciate that. There is no doubt Austin, you're an excellent coder. > I wish I could be as talented as you. But maybe you should take your > own advice and come down from your perch and actually work *with* us > mere mortals. It certainly would be better than these pointless > "lighting bolts". Trans, there are some ideas so bad that the only way to improve them is to eliminate them. That's *precisely* what I think of the ideas that have been mentioned here; not everyone is going to agree with me, of course. But where you have had other ideas that have needed improvement (at least IMO), I *have* made suggestions for improvement. There's at least one RCR out there of yours that I supported and/or made positive criticism toward improving. Don't get me wrong: I think that your thinking outside of the box is useful, and from time to time you'll have something that I can not only support, but I can adopt and use myself. I think, however, that you fall in love with your ideas to the point that you can't see any other way around the "problems" you're experiencing without changing how Ruby works. My problem with your suggestions, by and large, is that you seem too ready to change Ruby and not consider other directions or solutions. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca