Another Look at Namespaces


#1

Had a “light-bulb” over head moment and threw this together as a simple
demonstration. It’s prerry neat. THough is stffes from a few problems
of course 1) it probaby not very efficient 2) literal notions don’t
work and 3) it’s not dynamic. #3 could be solved if there were a way to
capture const_missing relative to a specific module/class (no
inheritance chain). #2 requires Ruby itself to look for, say String
class relatively instad of absolutely (potentially dnagerous?) of
course #1 is just one of this things :wink:

class Module
def namespace
Module::constants.each do |c|
tc = eval("::#{c}")
next if tc == self
begin
const_set c, tc.dup
rescue
begin
const_set c, tc.clone
rescue
#puts “Can’t copy #{c}”
end
end
end
module_eval %{
#class Object
# include self::Kernel
#end
include Kernel
}
end
end

try it out

class X
namespace

module Kernel
  module_function
  def p( x )
    puts "#=> #{x.inspect}"
  end
end

class String
  def upcase
    "#{self}!!!!!"
  end
end

def show
  p self.class.ancestors
  p "Hello" # literals don't work
  p String.new("Hello").upcase
end

end

x = X.new
x.show


#2

removed_email_address@domain.invalid wrote:

Had a “light-bulb” over head moment and threw this together as a simple
demonstration. It’s prerry neat. THough is stffes from a few problems
of course 1) it probaby not very efficient 2) literal notions don’t
work and 3) it’s not dynamic. #3 could be solved if there were a way to
capture const_missing relative to a specific module/class (no
inheritance chain). #2 requires Ruby itself to look for, say String
class relatively instad of absolutely (potentially dnagerous?) of
course #1 is just one of this things :wink:

When you say “literals don’t work”, what do you mean?

I get this:

irb(main):048:0> x.show
#=> [X, X::Kernel, Object, Kernel]
#=> “Hello”
#=> “Hello!!!”
=> nil

What are you expecting?


#3

On 6/3/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

Alex Y. wrote:
Notice that when you create a string via String.new you get the
exlamation marks. If you use the literal constructor you do not. That’s
because Ruby does not search for the String class relative to context
when instantiating literls. If it did, this could be a basis for
SELECTOR NAMESPACES.

…all of which sounds way too magic to me. The more I look at
selector namespaces, the less that I like them because they’re way too
magic. Sort of like the decision made in C++ to allow overloading of
compound assignment operators (+=, -=, etc.) so that c = c + b could
mean something entirely different than c += b.

I would feel very uncomfortable if basic language structures changed
on me randomly.

Inasmuch as selector namespaces are limited to allowing multiple
methods with the same name but different “namespaces”, I’ll support
them even though I can’t really see much value in them. Beyond that
… and I think we’re looking at something that is far more confusing
and abusable than any possible value it could provide.

-austin


#4

Austin Z. wrote:

methods with the same name but different “namespaces”, I’ll support
them even though I can’t really see much value in them. Beyond that
… and I think we’re looking at something that is far more confusing
and abusable than any possible value it could provide.

Well, I would tend to agree with you if were almost any other language.
But given’s Ruby dynamics, namely the ability to extend previsously
defined classes and modules, really put Ruby in a differnt ballgame.
Selector namespaces provide a way to manage that. I understand the
downside of having definitions change based on context, but that’s the
trade-off for the flexibility. I really believe Ruby should move foward
with this. But if it’s decided that this flexibility is not “good”,
then I think Ruby should just close shop on her classes and module
–once defined always defined. I do a lot of meta-coding and I find in
this area Ruby can still be rather frustrating to use b/c it really
hasn’t fully embraced itself as a meta-lanaguage.

T.


#5

On 6/3/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

hasn’t fully embraced itself as a meta-lanaguage.
Fortunately, the choice isn’t yours. I think that what you’re wanting
is going way too far into unnecessary and hard-to-understand arcana,
and the opposite of that is not closed classes. Selector namespaces
are about explicit method selection, not implicit method selection,
IMO.

-austin


#6

Alex Y. wrote:

What are you expecting?
Notice that when you create a string via String.new you get the
exlamation marks. If you use the literal constructor you do not. That’s
because Ruby does not search for the String class relative to context
when instantiating literls. If it did, this could be a basis for
SELECTOR NAMESPACES.

T.


#7

On 6/3/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

Austin Z. wrote:

Fortunately, the choice isn’t yours.
Wwhy do you have to go and do that? Does making a little digg like
that support your argument?

It’s not a dig. It’s a statement of fact: the choice isn’t yours. It
isn’t mine, either. However, you presented this as an either-or
proposition, which this most certainly is not. 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.

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

end

end

x = X.new
x.mystring #=> 0

(1) That’s not selector namespaces as I understand it.
(2) The fact that “String.new” is being used is an indication that
something is different.
(3) There’s no way that the alteration of basic syntactical rules could
possibly be easier to understand.

Far better to work with other people than around them, if at all
possible.

-austin


#8

Austin Z. wrote:

this area Ruby can still be rather frustrating to use b/c it really
hasn’t fully embraced itself as a meta-lanaguage.

Fortunately, the choice isn’t yours.

Wwhy do you have to go and do that? Does making a little digg like that
support your argument?

I think that what you’re wanting
is going way too far into unnecessary and hard-to-understand arcana,
and the opposite of that is not closed classes. Selector namespaces
are about explicit method selection, not implicit method selection,
IMO.

I just don’t see your point when what you say is unnecessry arcana
can already be done --indeed is already being done. There just happens
to be odd exceptions, due to the lack of a more managed approach. For
example, not unlike the one I already gave.

— foolib.rb —

class X
class String
def self.new ; 0 ; end
end
end

— bar.rb —

require ‘foolib’

class X
def mystring
String.new( “Extended!” )
end
end

x = X.new
x.mystring #=> 0

Just picking up bar.rb off the ground, so to speak, would indeed seem
pretty confusing. Why is String.new not doing what is should? But
obviously you have to know what’s up in foolib.rb. So already one is
subject to context-based behavior. With selector namespaces it actually
becomes less confusing because the namespace declaration would make it
clear that you need to be aware of how that namespace is adjusting the
system. And for the same reason it’s actually safer too. With no formal
means of handling it presently we are at the potential whims of each
other’s good extension habbits, which in effect limits are ability to
share code and conversely, our ability to expoint the potential of
extensions.

T.


#9

Austin Z. wrote:

On 6/3/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

Austin Z. wrote:

Fortunately, the choice isn’t yours.
Wwhy do you have to go and do that? Does making a little digg like
that support your argument?

It’s not a dig. It’s a statement of fact: the choice isn’t yours.

The fact that “the choice isn’t yours” isn;t the problem. And obvious.
It’s the “fortunately” part that is diggish and you know it.

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.

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

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

end

end

x = X.new
x.mystring #=> 0

(1) That’s not selector namespaces as I understand it.

Uh yea. Did you miss the point?

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

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

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

T.


#10

removed_email_address@domain.invalid wrote:

=> nil

What are you expecting?

Notice that when you create a string via String.new you get the
exlamation marks.
I wouldn’t expect to in any case without the .upcase call… Did you
mean this instead?

def show
p self.class.ancestors
p “Hello”.upcase # literals don’t work
p String.new(“Hello”).upcase
end


#11

Alex Y. wrote:

I wouldn’t expect to in any case without the .upcase call… Did you
mean this instead?

def show
p self.class.ancestors
p “Hello”.upcase # literals don’t work
p String.new(“Hello”).upcase
end

Yes I did. Thanks for the correction.

T.


#12

On 6/3/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

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


#13

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

:smiley: That last stastement, Austin! You’re too modest! :wink:

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 :wink:

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.

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”

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.


#14

Austin Z. wrote:

You’re right. It’s “mostly”. I am very … cautious about changing the
behaviour in core libraries and I almost never do so in anything that I
release. In a DSL that I have done for work, though, I have made a
very dangerous change (one that I have found necessary to document)
that makes the DSL itself much easier to use[1]. If I were doing this in
anything that would be combined with anything else, I wouldn’t make this
change. Period.

I agree that changing core behavior should not be done lightly, becasue
they reduce code readability. But DSLs can be even better for that, and
as you point out a core change may enhance that. I think you should be
able to share your code without having to worry so about it.

I would question the need to change Array#each rather than introducing a
new method. That’s the thing that I’ve found in my years of Ruby: the
need I have for modifying the core language’s operations are few and far
between. More likely, I need extra behaviour which suggests adding a
new method to the core class (in private code), but I think I can
count the number of times I’ve needed to override a core functionality
on three fingers and not use them all. :wink:

I’ve done a lot of “framework” coding --ways to enhance the overall
system, such as AOP and Annotations, plus I maintain a whole library of
extensions. So I’m completely on the other side of the spectrum. Of
course I too almost entirely avoid overriding core behavior, and stick
to additions, for obvious reasons.

Yet I think there is more potential here. The way I see it is like
Kernel. We can override any Kernel method we wish in our subclasses,
right? So what if the entire system came in via Kernel instead of being
split into two separate hierarchies: Kernel and Constant Lookup. You
may think that would lead to a train wrek, but I am not so sure of
that. People generally avoid the Kernel methods in their subclasses
unless they have a good reason for not doing so --I think the same
would hold true, and even more cautiously, when it comes to more
essential aspects of the core.

It is a false dichotomy. One does not have the choice between allowing
core extensions or not. Taking your example, what would the difference
be between:

%w(a b c).trans:each { … }
%w(a b c).trans_each { … }

Seriously? The former is the proposed selector namespace format for an
individual call.

I agree. That notation has very limited usefulness. BTW I though it
was?

%w(a b c).each:trans { ... }

I think that the only real difference would be:

with_namespace :trans do
%w(a b c).each { … } # is trans:each
end

That’s what I mean about being explicit. Your statements so far have
been focussed around implicit resolution of (selector) namespaces. And
that is the part that I oppose as much as possible. Implicit
behaviours tend to confuse people unnecessarily.

Well, I’m certainly not against explict namespaces. And in part I was
thinking of my example notation as more akin to private, protected and
public (even if it didn’t fully implement that way). So in that case
there’s still an explicit “area” in which the namespace applies. You
may be right about implicit namespaces, though I won’t discredit them
quite so readily --they would be akin to what one does when they
include a module in a class. I mean you have to know what the module
brings to the table to use work in that class, a namespace is the the
same idea, juut more extensive. Again I go back to the idea of the whol
system coming though the Kernel.

  end
puts "Here's some debug information."

T operator+=(const T& o);

The moment that I can define away what looks like it should be core
standard behaviour (that is, that the result of “x = x + b” and “x += b”
would be the same), I have not just given the user power, I have given
the user inappropriate power. The potential for misbehaviour and
everything else is significantly higher than the value afforded by
such redefinition. (I know why they allow it. It allows your +=
operation to be implemented efficiently on complex objects, but I
consider that to be premature optimisation most of the time.)

[snip]

I think that you wouldn’t want to know when literals are created, mostly
because literals are generally very small and multiply in your code like
rabbits.

Sure. I such things are far from any common use case. But I’m not sure
it should neccessarily be illegal? There may be very good reasons that
it is, but if it’s reasonably possible then having that avenue could be
very useful in some cases. Code inspection tools for instance would
probably be all over such abilities.

I think that what you may need to do with some of your proposals is step
back from them and think them through. You say you can’t see
consequenses so readily. The reality is that this is a skill that can be
trained just like any other. Sometimes, the better solution is no change
at all.

Well, sometimes I do and sometimes I don’t. Sometimes I think others
would have better insight so I ask. I’m not one of those guys whose
dead set against asking for directions --if you take my meaning. You
think maybe I should spend more time considering before asking. In some
cases you’re right. And I’ll try to do that more (and actually I have
already been doing so).

Okay; I may have been unfair in my characterisation of how you viewed
this. However, there are cases where it would have bombed on Unix, too
(usually from the command-line since the shell does meta character
expansion). But Windows isn’t the only system to limit punctuation,
although it’s probably the strictest at this point.

Yep. More goog reasons I was deads wrong about that.

Um. I would disagree with you philosophically. However, I will modify my
statement to suggest that you adopt positions and treat them as
something that a language change should fix when it’s usually far easier
and cleaner for the programmer to change what they do.

[snip]

has made that I strongly disagree with (->() {}, anyone?). I’m not at
all suggesting that there aren’t things about Ruby that don’t need
fixing, but I will look at changing Ruby last. You may not look at
changing Ruby first, but your public persona here on ruby-talk and on
ruby-core is … one of the first voices when this comes up.

Well, I think you misunderstand me. I enjoy toying with ideas realated
to the language itself. Just because I present such an idea doesn’t
mean that I am proposing it a la RCR. I’m just interested in exploring
the possibilities. It’s sort of a hobby. So I think your misjudging my
modus operandi here.

No, not meaningless hyperbole. Meaningful hyperbole. IIRC, you wanted to
be able to do “require 'nano:classes/string” because you didn’t want to
reorganise your source repository or use a Rake task to reorganise it on
packaging. But simply changing Ruby for that isn’t the right answer, and
visually your desired change don’t provide useful meaning (IMO).

No. That’s not it at all. Think you mixed up two issues into one that I
was having about the same time --which can be interrelate, so i
understand why you may have thought that. But the colon notion is
specifically for a way to do versioning efficiently and independently
of a packaing system. That’s all. While it’s functionality relates to
the organization ones distributed files, the organization of the source
repository is not the causal issue.

[1] def Object.const_missing(name); name.to_s; end

Hmm… too bad you can’t capture cont_missing relative a module or
class.

T.


#15

On 6/5/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

Austin Z. 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? […]

You’re right. It’s “mostly”. I am very … cautious about changing the
behaviour in core libraries and I almost never do so in anything that I
release. In a DSL that I have done for work, though, I have made a
very dangerous change (one that I have found necessary to document)
that makes the DSL itself much easier to use[1]. If I were doing this in
anything that would be combined with anything else, I wouldn’t make this
change. Period.

[…] 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.

I would question the need to change Array#each rather than introducing a
new method. That’s the thing that I’ve found in my years of Ruby: the
need I have for modifying the core language’s operations are few and far
between. More likely, I need extra behaviour which suggests adding a
new method to the core class (in private code), but I think I can
count the number of times I’ve needed to override a core functionality
on three fingers and not use them all. :wink:

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.

It is a false dichotomy. One does not have the choice between allowing
core extensions or not. Taking your example, what would the difference
be between:

%w(a b c).trans:each { … }
%w(a b c).trans_each { … }

Seriously? The former is the proposed selector namespace format for an
individual call. I think that the only real difference would be:

with_namespace :trans do
%w(a b c).each { … } # is trans:each
end

That’s what I mean about being explicit. Your statements so far have
been focussed around implicit resolution of (selector) namespaces. And
that is the part that I oppose as much as possible. Implicit
behaviours tend to confuse people unnecessarily.

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.

See above for the explicit selector namespace resolution. Selector
namespaces is about method namespacing, not class namespacing. There are
already well-defined rules for the resolution of class (and module)
namespacing, and they’re going to become less confusing in Ruby2. With
regard to examples of what could go wrong?

class X
class String
def initialize(*args, &block)
@value = 0
end

  def to_s
    @value.to_s
  end

  def to_str
    to_s
  end
end

puts "Here's some debug information."
puts String.new("More debug information.")

end

If you have dynamic resolution of the class and constructor based on
literals, you will break the behaviour of String (and very badly) for
everything else (that is, the first example would do the same as the
second example). As I said when I first responded, this is just like
the ability in C++ to define:

T operator+(const T& o);
T operator+=(const T& o);

The moment that I can define away what looks like it should be core
standard behaviour (that is, that the result of “x = x + b” and “x += b”
would be the same), I have not just given the user power, I have given
the user inappropriate power. The potential for misbehaviour and
everything else is significantly higher than the value afforded by
such redefinition. (I know why they allow it. It allows your +=
operation to be implemented efficiently on complex objects, but I
consider that to be premature optimisation most of the time.)

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.

Um. I think that is kind of the point. X::String isn’t a localized
extension to ::String. It’s a wholly new class, even if it inherits. How
would you want to extend String locally to your class so that in
“your” namespace, you know that all Strings have certain behaviours?

class X
class ::String # confusing and inappropriate
end
end

There’s no clean syntactic way to do this that doesn’t end up affecting
everything else. I mentioned it earlier, but it’s my understanding that
class/module namespaces and (method) selector namespaces will be
independent of one another.

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.

I think that you wouldn’t want to know when literals are created, mostly
because literals are generally very small and multiply in your code like
rabbits.

was interesting because it highlighted an idea: that of the core being
portable, duplicatable and reusable even within the same program.

An idea, that ultimately, I don’t think would work.

but I’ll even more readily adopt a better solution if one is presented
me.

I think that what you may need to do with some of your proposals is step
back from them and think them through. You say you can’t see
consequenses so readily. The reality is that this is a skill that can be
trained just like any other. Sometimes, the better solution is no change
at all.

[…]

file scheme, but by doing some simple escaping myself, it works well
enough.

Okay; I may have been unfair in my characterisation of how you viewed
this. However, there are cases where it would have bombed on Unix, too
(usually from the command-line since the shell does meta character
expansion). But Windows isn’t the only system to limit punctuation,
although it’s probably the strictest at this point.

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.

Um. I would disagree with you philosophically. However, I will modify my
statement to suggest that you adopt positions and treat them as
something that a language change should fix when it’s usually far easier
and cleaner for the programmer to change what they do.

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.

Didn’t say that.

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 :wink:

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.

Trans, I may be your most vocal critic, but I know I’m not the only one.
I also know you have people who admire the work that you’ve done, and I
would be the last to suggest that you’ve done nothing for Ruby. You have
done things for Ruby, but I think it’s a little more than “occasional
misjudgements” (your word, not mine). I think what I’m really trying
to say is that you often appear far more willing to tinker with Ruby,
the language, rather than trying to look at the problem from a different
perspective.

There are things that I would fix with Ruby. There are choices that Matz
has made that I strongly disagree with (->() {}, anyone?). I’m not at
all suggesting that there aren’t things about Ruby that don’t need
fixing, but I will look at changing Ruby last. You may not look at
changing Ruby first, but your public persona here on ruby-talk and on
ruby-core is … one of the first voices when this comes up.

paint themselves into a corner that required it.)
A trainwreck? Meaningless hyperbole.

No, not meaningless hyperbole. Meaningful hyperbole. IIRC, you wanted to
be able to do “require 'nano:classes/string” because you didn’t want to
reorganise your source repository or use a Rake task to reorganise it on
packaging. But simply changing Ruby for that isn’t the right answer, and
visually your desired change don’t provide useful meaning (IMO).

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”

Fair enough.

[…]

-austin
[1] def Object.const_missing(name); name.to_s; end


#16

On 6/6/06, removed_email_address@domain.invalid removed_email_address@domain.invalid wrote:

[1] def Object.const_missing(name); name.to_s; end
Hmm… too bad you can’t capture cont_missing relative a module or
class.

You can, but you have to be explicit about it. The whole point of
making this change was that my DSL’s “scope” is global, and is
therefore limited to globally-scoped changes. I’m not sure what I’d do
to fix it, but I wanted to be as implicit as possible here.

-austin