Re: Another Look at SELECTOR NAMESPACES

Austin Ziegler wrote:
>
> 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.

Okay let me put it this way: Do you find it advantageous to be able to
change/extend core/standard libs? Since you are "mostly happy with the
state of Ruby as it is now." I'll assume for the moment that your
answer is also "mosty". Okay so then lets take the simple scenario. I
change the behavior of an core class, say Array.each, for some
particular need. Then you come across that tool and realize you could
reuse that code in one of your progress, only to dicover it's causing
some very unexpect errors else where in you code. The simple fact this
this is readily possible, convinces me that Ruby would do well by
having a means of localizaing the effects of such core changes. While I
personally there are more advantages than disadvantages to allowing
such core extension. If Ruby does not plan to offer some means of
managing them, the in turn I think it woud better at least to limit
those changes, say  to additions, but not redefintions. You say it's a
fasle dicotomy. But it is not. It is  a very real dicotomy IF we are to
resolve the problem this scenario highlights.

> 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.

You may well be right, but I would like to see some examples of the
issues you feel that make this so terrible. Moreover I don't exaclty
see how you plan to do any sort of namespaces without dynamic
resolution.

As for core syntax I assume you mean literal. Well if the literal forms
don't take part in namespaces than what's the point? Otherwise my
localized extension to String would have no effect. Perahps you just
men effecting the literal constructors --i.e. their using #new like
everything else. Well, I wasn't refering to that neccessarily in my
original post. But one certainly does wonder if it is possible. Perhaps
it is not, though I suspect it's just tricky. Now whether the
ramifications merit the usage I can't say. I know it already limits
some code monitoring capabilities --for instance I can't log the
creation of evey string. But that's not a big deal.

> > 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.

No. First of all I wasn't complaining. I was just pointing out the this
namespace implementation that I was *playing* with would not work fully
becuase literal constructors do not resolve to their respective classes
the same way that the named constant constructors do. I dion't every
really even take the implementation seriously. I just thought it was
interesting because it highlighted an idea: that of the core being
portable, duplicatable and reusable even within the same program.

> 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.

Well, you may mistake me for Nabu or someone who can see consequenses
so readily. One of the reasons I bring things up on the list is to get
help in seeing the utility or finding better alternatives. Certainly I
will argue strongly for something that I think has significant merit,
but I'll even more readily adopt a better solution if one is presented
me.

> 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.

:D That last stastement, Austin! You're too modest! ;)

Okay, I know what you mean. Yes, I appreciate that. I've actually been
suprised by it on occasion.

> Other times? We get your ill-informed rants about the quality of
> RubyGems ([ruby-talk:158548]),

I'm not exactly sure why you say ill-informed, but anyway, I'm not all
knowing in any case. And even so I think I made some very valid points
in that post. I recall you were very upset by it, which I don't quite
understand why.

> your hare-brained "namespaced" load paths
> ([ruby-core:06001]),

Sigh. Whatever, Austin. I'll just roll with it.

> your use of punctuation in filenames and pretending
> that it's a general problem (various places, including
> [ruby-core:05988]),

Pretending? I saw it as a general problem because requiring a file on a
Unix system worked but bombed on Windows. So yea I saw that as pretty
general. I thouhg at first it might help if Ruby esacped those
characters. I realized in discussions later that it's not really a
domain Ruby is going to help. So you see, by making that suggestion I
learned it wasn't a good one --and that's great. I might add that I
ultimately  took some advice of yours (among others) and got rid of the
escaped characters. I no longer have a exact one for one method to file
scheme, but by doing some simple escaping myself, it works well enough.

BTW there is no such thing as a general *problem*. All problems are
personal and specific, but by talking about our problems they may have
general ramifications.

>   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.

Well, you can just chalk me up as being stupid then, I guess.

To be honest I find your statement overengineered. Since you've never
bother to actually exlpain it (again) I take it to mean that you think
I want Ruby changed (computer solution) to solve my personal
programming whims (human problem). ie. Matz help! Please add
#solve_all_toms_problems to core. Thanks. (Damn that would be sweet ;)

If that's what you mean then it's simply not true . I may make
occasional misjudgements in that direction. But that's a far cry from
seeking it out.

> 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.)

A trainwreck? Meaningless hyperbole.

> 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.

Yes and no. It would be neccessary for namespaces implemented according
to my example. You have to understand, this implementation was not
meant to be a suggestion for how Ruby should do it neccessarily, I was
just showing the idea I had that got pretty close to implementing
namespaces. I though it was interesting for that reason and shared it,
then pointed out hwy it didn;t work becasue of how RUby worked. You
somehow turned that around as me saying Ruby should work differently to
accomidate my implmentation. But that's not true -- that's the way
you're interpreting things. A la your "enginering problems"

> 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.

Okay, well thanks for your candor. I appreciate that.

I think maybe I come off that way b/c I probably spend more time
thinking about the languages limitations and potentials than anyone
else (probably including matz). When I run into certain issues, of
course I could work around, but sometimes I wonder why I am having to
work around. When I further see that issue has a general character that
effects more than just myself, I wonder how it can be resolved in a
general way, rather then my just working around it and forgetting about
it. And that why I post my ideas as such -- to help see how it might
address the needs (or not) or others. No doubt I sometimes make
mistakes anywhere along that line of thought. But I think it's better
that I try rather than avoid it. It what sort of lets me think outside
of the box --and as long as I can remember it's how I have always been.

T.