ruby wish-list

[Gordon Thiesfeld]

You want to create a two-dimensional array, right?
It works when you add square braces:

a = [1,2,3]
a.map{|n| [n,n] }

Yeah I'm just a little lazy and dislike all the brackets

No brackets, huh?

a = [1,2,3] => [1, 2, 3]
a.zip(a)

=> [[1, 1], [2, 2], [3, 3]]

 

[Tim Hunter]

You want to create a two-dimensional array, right?
It works when you add square braces:

a = [1,2,3]
a.map{|n| [n,n] }

Yeah I'm just a little lazy and dislike all the brackets

I read somewhere that the best computer in the world was the one that
that Scotty uses on Star Trek, because no matter what he wanted to do he
could program it in two or three button presses.

Until we get one of Scotty's computers, though, programming requires
typing. Lots and lots of typing. Maybe a little less with Ruby than,
say, with Java, but still...lots.

 

[Damjan Rems]

Since this thread is alive again I am throwing in my wish which occured
to me in last months.

I wish parameters can be omited when calling methods with parameter
which have default values set and is (are) in the middle ro begining of
the parameter set.

Example:

def myMethod(a=1, b=2, c=3)
end
myMethod(3,,5)
myMethod(,,5)

This way I don't have to know the value of parameter b (which I am also
not interested in) and the called method would use default defined value
of 2.

of course if method is defined as:

def myMethod(a=1, b, c=3)
end
myMethod(3,,5) => should throw an error.


by
TheR

 

[Robert Klemme]

Next wish
I wish that you could make arrays more easily. As in

a = [1,2,3]
a.map{|n| n,n }

and it would work
-R

You can do

irb(main):002:0> Array.new(3) {|n| [n,n]}
=> [[0, 0], [1, 1], [2, 2]]
irb(main):003:0> (1..3).map {|n| [n,n]}
=> [[1, 1], [2, 2], [3, 3]]

But you don't get rid of the brackets that way.

robert

 

[Thomas Wieczorek]

I wish parameters can be omited when calling methods with parameter
which have default values set and is (are) in the middle ro begining of
the parameter set.

I have already replied once and I thought and still think that
something like mymethod(2, ,3) looks kind of ugly.
But since then I took a look at Python and I like how it works with
default parameters and default values:

Example:

def myMethod(a=1, b=2, c=3)
end

You can call myMethod(b=5) and the other default values aren't
changed. I think this looks more beautyful than leaving empty space
between commas.
Ruby 1.9 supports named parameters, but I don't know anything about
it. Just take a look at it and see if it does what you want.
You can still work with hashes:
def myMethod(opts = {})
defaults = {:a => 1, :b => 2, :c=> 3}
opts = defaults.merge(opts)
#whatever
end

 

[Roger Pack]

Ruby 1.9 supports named parameters, but I don't know anything about

it. Just take a look at it and see if it does what you want.

Appears the new syntax is
def lolmatz(param1, param2 = 'second', param3)
print param1, param2, param3
end
lolmatz('first', 'third') # prints 'firstsecondthird'

and it works.
Proc's also can have default parameters that way, too.
So I guess my wish would be a more intuitive style still, like
lolmatz('first', param3='third')
which worked out of the box

Another would be (of course) easier multi-line comments (more
intuitive), like
###
comments!
###

That would be nice.

As a final note, in retrospect it would be possible to create a 'custom'
hash that inherited from the Hash class and had the functionality as if
it were ordered. Go Ruby for flexibility.

Thanks all
-R

 

[Gary Wright]

intuitive), like
###
comments!
###

=begin
lots of
comment
lines
=end

Gary Wright

 

[Roger Pack]

Gary Wright wrote:

yep one just like that that was more intuitive to me, since I always
forget this one

 

[Roger Pack]

If I wanted something "intuitive",

/*
I'd probably prefer something like this,
*/

Yeah that'd be sweet.

I believe this next wish has been mentioned before, but...
I wish you could call functions with the same name from arbitrary
ancestor classes.

class A
def run
print 'A'
end
end
class B < A
def run
print 'B'
end
end

test = B.new
test.run # prints B
test.class.run_as(A).run # prints 'A'


Thanks again.
-R

 

[Trans]

Yeah that'd be sweet.

I believe this next wish has been mentioned before, but...
I wish you could call functions with the same name from arbitrary
ancestor classes.

class A
def run
print 'A'
end
end
class B < A
def run
print 'B'
end
end

test = B.new
test.run # prints B
test.class.run_as(A).run # prints 'A'

See Facets Kernel#as.

http://facets.rubyforge.org

T.

 

[Roger Pack]

See Facets Kernel#as.

http://facets.rubyforge.org

T.

Wow facets looks really nice! It even has the multi-hash that was a
wish a few posts ago, plus some other utilities that I've had to write
from scratch before [but not anymore]. Rock on.
-R

 

[Roger Pack]

Next wish
I wish you could have distinguishable separatable name-spaces, something
along the lines of

class Abc
end
namespace one
class Abc
def func1
end
end
end

namespace two
# class Abc will NOT have func1, right here
end

ok maybe it wouldn't be all that widespread used, but somewhat useful
for keeping code nice and separate.
Thanks for reading
-R

 

[Chris Shea]

Next wish
I wish you could have distinguishable separatable name-spaces, something
along the lines of

class Abc
end
namespace one
class Abc
def func1
end
end
end

namespace two
# class Abc will NOT have func1, right here
end

ok maybe it wouldn't be all that widespread used, but somewhat useful
for keeping code nice and separate.
Thanks for reading
-R

Can you show a use case where using modules as namespaces isn't enough?

 

[Robert Klemme]

Can you show a use case where using modules as namespaces isn't enough?

That was my first reaction as well. But now I suspect that Roger wanted
::Abc and :ne::Abc to be the _same class_ but method func1 should only
be visible in namespace one. With modules there were two distinct
classes that would not have anything in common. In this particular case
the behavior could be emulated with inheritance:

class Abc
end

module one
class Abc < ::Abc
def func1
end
end
end

but it would not be the same and not work in all cases where the wished
for feature would work. I believe the concept has been discussed under
the term "selector namespaces" numerous times here. I cannot remember
the current status of this feature though.

Personally I am not yet convinced that the feature would be so great.
My doubts are fed by the increased complexity of the language
implementation as well as complexity of the code that uses this feature.
For example, what happens in this case:

class Foo; end

module Bar
class Foo
def bar_meth; end
end

class Inherited < Foo
def test
bar_meth # ok here because in Bar
end
end
end

class WhatNow < ::Bar::Inherited
def test2
test # error or not?
bar_meth # error or not?
end
end

Kind regards

robert

 

[Roger Pack]

Yeah the only thing I can think of it being useful for would be when you
are 'meta-running' code

I got the idea as python doctests can run each file's doctest in a
'separate namespace' so that they don't munge each others tests.
I suppose you can accomplish about the same thing by [as rails
active_support does] keeping track of which new constants are created
during a test and tearing them down.
Another use would be if you were running multiple rails instances with
the same ruby--you might want them each to live in distinct lands.

classes that would not have anything in common. In this particular case
the behavior could be emulated with inheritance:

Interesting point. I agree with you that it would add some serious
complexity, though, which might be a bad thing.

Take care.
-R

 

[Robert Klemme]

I wish this worked

SyntaxError: compile error
(irb):3: syntax error, unexpected tASSOC, expecting '}'
a {:b => true}
^
from (irb):3

irb(main):001:0> def a(x)end
=> nil
irb(main):002:0> ab=>true)
=> nil
irb(main):003:0>

I have no idea why it doesn't consider a hash a parameter.

Precedence.

Cheers

robert

 

[Gordon Thiesfeld]

Precedence.

Yeah for some reason it is considering my function a block a higher
predencdence than a hash parameter.
So my next wish would be:
That ruby-core would allow us to make suggestions for how to better
their error messages
And also [sigh] that hashes and blocks used a different syntax, or that
the ambiguity noted could be overcome.
Cheers.

def a(hash)
hash
end => nil
a :a => false, :b =>true

=> {:a=>false, :b=>true}

 

[Robert Klemme]

Yeah for some reason

That "some reason" is probably the language's syntax definition.

it is considering my function a block a higher
predencdence than a hash parameter.
So my next wish would be:
That ruby-core would allow us to make suggestions for how to better
their error messages

I have never heard someone was turned down who made a reasonable suggestion.

And also [sigh] that hashes and blocks used a different syntax, or that

Not going to happen. Just think of the mess that would do to existing code.

the ambiguity noted could be overcome.

Is it just me or does this issue come up rarely? My impression is
that people stumble over it at most once and never again. This does
not feel like a big deal - certainly was never for me. But of course
YMMV.

Cheers

robert

 

[Roger Pack]

irb(main):001:0> def a(x)end
=> nil
irb(main):002:0> ab=>true)

Wow. Rock on. Now that you've pointed out this syntax I find it
addictive and use it a lot.

My next wish:
that
string =~ 'abc'

would work. It's not a regex, but I would imagine it makes sense to
auto-convert it
At least I'd use it.
-R

 

[Roger Pack]

All right ruby-genie. My next wish!
That 1.9 had an option that represents a cross between thread models 2
and 3[1] [i.e. sometimes threads could run simultaneous, a la].

guaranteed_thread_safe do
# thread multi threaded code
end

Though I suppose this is accomplishable using some C code, currently.
Thanks genie!
-R


[1] http://www.atdot.net/yarv/rc2006_sasada_yarv_on_rails.pdf