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
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
On Fri, Mar 28, 2008 at 12:21 AM, Roger P. [email protected]
wrote:
Next wish
I wish that you could make arrays more easily. As ina = [1,2,3]
a.map{|n| n,n }and it would work
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
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
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
I wish that you could make arrays more easily. As ina = [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
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 W. wrote:
yep one just like that that was more intuitive to me, since I always
forget this one
=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=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), likecomments!
=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ā
Thanks again.
-R
On Apr 7, 1:01 pm, Roger P. [email protected] wrote:
ancestor classes.
endtest = B.new
test.run # prints B
test.class.run_as(A).run # prints āAā
See Facets Kernel#as.
T.
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
end
ok maybe it wouldnāt be all that widespread used, but somewhat useful
for keeping code nice and separate.
Thanks for reading
-R
See Facets Kernel#as.
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 ::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
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
def a
end
=> nila {: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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs