Ruby wish-list

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

On Fri, Mar 28, 2008 at 12:21 AM, Roger P. [email protected]
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] }

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:

On Thu, Mar 27, 2008 at 6:34 PM, Roger P. [email protected]
wrote:

No brackets, huh?

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

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.

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

On Fri, Mar 28, 2008 at 8:34 AM, Damjan R. [email protected] 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

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

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

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

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.

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.

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

On Apr 7, 1:01 pm, Roger P. [email protected] 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.

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

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

On Apr 12, 10:49 am, Roger P. [email protected] wrote:

end

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

Can you show a use case where using modules as namespaces isnā€™t enough?

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

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

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