I think this has come up before in other issue requests, at the least

in one variant or the other (if I recall correctly, Hiroshi Shibata

also suggested some variant that is a bit similar to your "import"

example, but I do not remember the full issue's content; may have

been some months ago or perhaps a few years).

I also had a few ideas; e. g. to be able to attach meta-information

to class/modules (that way we can find out who is the original author,

when and what changes may have been made etc...).

I agree with this comment here a lot by the way:

import :"A::B::C::D", as: :E

Not necessarily about using the name "import", but with the ability

to re-define namespaces at require time. We can of course already

do so by including modules and removing (older) constants, but I

always thought it may be more elegant to be able to do so the moment

we require ruby code.

I am not so sure about the rest of the suggestion. I don't have any

particularly strong pro or con opinion, although I am a bit wary.

Part of the suggestions all are a bit complicated, API-wise and from

the scope. I understand that, if we want more flexibility, we may

need to be able to have a way to add code which requires more characters

and such. But one thing that is great in ruby, even if we say that

"having no namespaces is a disadvantage", is that using modules and

classes on the toplevel space, is very, very simple. People very

quickly understand that concept.

class Cat def meow puts 'The cat meows.' end end

With namespaces as suggested here, we may add another layer of

complexity; and while I do agree with some stronger form of

control possible over "namespaces" in ruby, I am not sure if

the proposal in this form is having a good trade-off. But as I

wrote, it's not that I have a big opinion either way - I think

the biggest concern I have had in regards to namespaces was

when ruby were to use PHP's "solution" and syntax for

namespaces ... :P

As for refinements - the odd thing is that I agree behind the

proposal and ideas, but the syntax and API is so weird to me

and it feels ... strange to use them. I also have no alternative

suggestion, so this is not good; best way would be to have

both namespaces, namespace scopes and refinements in a single

issue with a great, beautiful syntax. :D

(We should however had also consider whether the status quo

is actually better than the proposed changes. And to some

extent I'd rather use a status quo than want to transition

into changes that do not seem to be as worthwhile to be

had - even though I actually agree with a LOT on what is

said about namespaces, refinements etc...)

As for requiring ruby code, I agree. In particular for larger

projects written in ruby, it may be useful to not only have

more control, but make managing that ruby code simpler. In

your example, the author who wrote the code must have forgotten

to require some other files; but I understand that this may

be tedious if one has a large project with lots of .rb files.

Then there are also circular warnings which are no fun at all.

I am confident that this may improve in the long run - matz

always said that ruby is for humans rather than computers

and that the core team will listen to (and prioritize on)

"real problems" and painpoints people have when writing

ruby code. And personally I think that a lot of these problems

emerge when one writes a lot of ruby code and has lots of

ruby files, too.