Ruby wish-list


#101

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

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

and it would work :slight_smile:
-R


#102

On Fri, Mar 28, 2008 at 12:21 AM, Roger P. removed_email_address@domain.invalid
wrote:

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

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

and it would work :slight_smile:

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] }


#103

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


#104

On Thu, Mar 27, 2008 at 6:34 PM, Roger P. removed_email_address@domain.invalid
wrote:

No brackets, huh?

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

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


#105

Roger P. wrote:

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

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.


#106

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


#107

On Fri, Mar 28, 2008 at 8:34 AM, Damjan R. removed_email_address@domain.invalid wrote:

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


#108

On 28.03.2008 00:21, Roger P. wrote:

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

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

and it would work :slight_smile:
-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


#109

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

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 :slight_smile:
-R


#110

Gary W. wrote:

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

=begin
lots of
comment
lines
=end


#111

On Thu, Apr 03, 2008 at 02:06:21AM +0900, Roger P. wrote:

Gary W. wrote:

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

=begin
lots of
comment
lines
=end

Actually, I prefer:

=begin
this,
=end

over this.

If I wanted something “intuitive”,

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

since that’s what I’m used to for multiline comments. On the other
hand,

=begin
this seems a lot more Ruby-idiomatic to me,
=end

so I like it just fine.


#112

On Apr 2, 2008, at 12:10 PM, Roger P. wrote:

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

comments!

=begin
lots of
comment
lines
=end

Gary W.


#113

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’

:slight_smile:
Thanks again.
-R


#114

On Apr 7, 1:01 pm, Roger P. removed_email_address@domain.invalid wrote:

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


#115

Next wish :slight_smile:
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 :slight_smile:
-R


#116

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


#117

On Apr 12, 10:49 am, Roger P. removed_email_address@domain.invalid wrote:

end

Posted viahttp://www.ruby-forum.com/.

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


#118

On 12.04.2008 20:40, Chris S. wrote:

end

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 ::one::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. :slight_smile:

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


#119

Robert K. wrote:

On 12.04.2008 20:40, Chris S. wrote:

end

Can you show a use case where using modules as namespaces isn’t enough?
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


#120

I wish this worked :slight_smile:

def a
end
=> nil

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

I have no idea why it doesn’t consider a hash a parameter.
-R