definitively a bug

Die_Optimisten · 5 December 2021 11:29

Hi

puts {a:'a'} # -> nil, no error? - just an often used basic method...

puts { a: 'a' }

Opti

soroosh_sarabadani · 5 December 2021 12:43

Hi,

The first example is translated to a block with no argument, this block
calls a method named "*a*" with 1 argument with value `*:a*`.

But due to the space between the colon and `a`, it's not understood as a
symbol.

If your intention is printing a hash, you have to write it like this:

puts ({a:'a'})

Lack of the parens causes ruby to treat that definition as *Ruby block, *
like:

puts () { a(:a) }

Also as a general note, would be great if you could provide more context in
the messages being sent, it helps others to understand your points easier
and as the result you'll receive clearer answer

Cheers,

···

On Sun, 5 Dec 2021 at 12:30, Die Optimisten <inform@die-optimisten.net> wrote:

Hi

puts {a:'a'} # -> nil, no error? - just an often used basic method...

puts { a: 'a' }

Opti

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

PYH1 · 6 December 2021 01:03

How to differ a block and a hash from ruby? they can be defined both by {}.

Thanks.

···

On 2021/12/5 8:43 下午, soroosh sarabadani wrote:

The first example is translated to a block with no argument, this block calls a method named "*a*" with 1 argument with value `*:a*`.

Matthew_Kerwin · 6 December 2021 02:26

Lexically. A block is always only after a function's parameters.

···

On Mon, Dec 6, 2021 at 11:06 AM yonghua <yonghua@laposte.net> wrote:

How to differ a block and a hash from ruby? they can be defined both by {}.

Thanks.

~~~
# blocks
foo() {}
foo {}
foo(bar, baz) {}

# hash
foo({})
~~~

or by spelling:

~~~
foo do ; end # block
~~~

Cheers
--
Matthew Kerwin
https://matthew.kerwin.net.au/

Die_Optimisten · 6 December 2021 10:58

Hi
Thank you,
I'm just pointing out that 1) this is not what one would expect,
2) If it can't be parsed, there should be an error (method a does not
exist; puts has no blocks! )
Opti

···

Am 05.12.21 um 13:43 schrieb soroosh sarabadani:

Hi,

The first example is translated to a block with no argument, this
block calls a method named "*a*" with 1 argument with value `*:a*`.

But due to the space between the colon and `a`, it's not understood as
a symbol.

If your intention is printing a hash, you have to write it like this:

puts ({a:'a'})

Lack of the parens causes ruby to treat that definition as
*Ruby block, *like:

puts () { a(:a) }

Also as a general note, would be great if you could provide more
context in the messages being sent, it helps others to understand your
points easier and as the result you'll receive clearer answer

Cheers,

On Sun, 5 Dec 2021 at 12:30, Die Optimisten <inform@die-optimisten.net > <mailto:inform@die-optimisten.net>> wrote:

    Hi

     puts {a:'a'} # -> nil, no error? - just an often used basic
    method...

    puts { a: 'a' }

    Opti

soroosh_sarabadani · 6 December 2021 11:22

The method should exist at the context of execution rather definition, so
it's totally fine to define a block that calls a non existing method.
See this gist:

gist.github.com

https://gist.github.com/s-soroosh/1eef46183a8607123e450c9fed8ef422

runtime_method_provider.rb

class P
  def method1(x)
    puts x
  end

  def run_proc(p)
    self.instance_exec &p
  end
end

This file has been truncated. show original

The blocks also can be used within a method conditionally.

That being said, I agree that debugging such issues in the code is not
straightforward but I doubt they can be considered as bug.

···

On Mon, 6 Dec 2021 at 11:59, Die Optimisten <inform@die-optimisten.net> wrote:

Hi
Thank you,
I'm just pointing out that 1) this is not what one would expect,
2) If it can't be parsed, there should be an error (method a does not
exist; puts has no blocks! )
Opti

Am 05.12.21 um 13:43 schrieb soroosh sarabadani:

Hi,

The first example is translated to a block with no argument, this block
calls a method named "*a*" with 1 argument with value `*:a*`.

But due to the space between the colon and `a`, it's not understood as a
symbol.

If your intention is printing a hash, you have to write it like this:

puts ({a:'a'})

Lack of the parens causes ruby to treat that definition as *Ruby block, *
like:

puts () { a(:a) }

Also as a general note, would be great if you could provide more context
in the messages being sent, it helps others to understand your points
easier and as the result you'll receive clearer answer

Cheers,

On Sun, 5 Dec 2021 at 12:30, Die Optimisten <inform@die-optimisten.net> > wrote:

Hi

puts {a:'a'} # -> nil, no error? - just an often used basic method...

puts { a: 'a' }

Opti

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Ryan_Davis1 · 7 December 2021 05:47

I'm just pointing out that 1) this is not what one would expect,

A common error I keep seeing in your posts is to conflate what YOU do not expect with what the general public does not expect. Just because YOU do not expect it does not mean it confuses the rest of us documentation reading rubyists.

And before anyone comes to their defense... They've been doing this crap for FIVE YEARS. It's all archived. This is trolling behavior.

2) If it can't be parsed, there should be an error

It was parsed, and correctly. There was no error. Passing a block to a method that doesn't use it is not (necessarily) an error.

···

On Dec 6, 2021, at 02:59, Die Optimisten <inform@die-optimisten.net> wrote:

Die_Optimisten · 7 December 2021 13:55

Hi
Yes, maybe most people are not concerned with such "special behaviours".
My opinion is that (to avoid poorly to find programming errors), that
possible errors should be shown (->throwing an error).
Besides I read (don't remember where), that it is good programing style
to check for a block.

puts has no usage of the block, so _I_ believe, there should be an error
thrown if calling with a block.
I (everyone?) would like to be able to use it [whole Ruby] "as expected"
without having the need of reading (too much) documentation, making the
language easier to use.
It's not trolling, I want to speak for a better Ruby... - so
highlighting what I don't feel as 'expected';
I believe, I'm not the only one [but sure, everybody can be wrong].
So everybody can tell us his/her opinion!

_I_ believe "doing other things than expected" (like executing puts with
a block) should be telled to the programmer (warning or failure),
conceiving as a advantage.
- Practice shows that this leads to asking for the details of blocks and
hashes...
Therefore _I_ think it's okay to show up such problems to all of us.

Opti

···

Am 07.12.21 um 06:47 schrieb Ryan Davis:

On Dec 6, 2021, at 02:59, Die Optimisten <inform@die-optimisten.net> wrote:

I'm just pointing out that 1) this is not what one would expect,

A common error I keep seeing in your posts is to conflate what YOU do not expect with what the general public does not expect. Just because YOU do not expect it does not mean it confuses the rest of us documentation reading rubyists.

And before anyone comes to their defense... They've been doing this crap for FIVE YEARS. It's all archived. This is trolling behavior.

2) If it can't be parsed, there should be an error

It was parsed, and correctly. There was no error. Passing a block to a method that doesn't use it is not (necessarily) an error.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Austin_Ziegler5 · 7 December 2021 14:44

What you’re asking for is excess strictness at runtime, which would
make Ruby not Ruby. Remember that Ruby’s principle of least surprise
is better understood as "principle of Matz’s least surprise".

It is not, and should never be, an error to pass a block to a function
that doesn’t use it, in part because of Ruby’s extreme dynamism.
Trying to detect this "error" at parse time is impossible, and nothing
stops someone from doing:

module Kernel
  alias __original_puts puts
  def puts(*args)
    args = args.map { |arg| arg } if block_given?
    __original_puts(*args)
  end
end

puts "Passing a block to puts is an error" do |arg| arg.sub(/\bis\b/,
"is not" end

Stop confusing your limitation of imagination with a universal one.

-a

···

On Tue, Dec 7, 2021 at 8:56 AM Die Optimisten <inform@die-optimisten.net> wrote:

Hi
Yes, maybe most people are not concerned with such "special behaviours".
My opinion is that (to avoid poorly to find programming errors), that
possible errors should be shown (->throwing an error).
Besides I read (don't remember where), that it is good programing style
to check for a block.

puts has no usage of the block, so _I_ believe, there should be an error
thrown if calling with a block.
I (everyone?) would like to be able to use it [whole Ruby] "as expected"
without having the need of reading (too much) documentation, making the
language easier to use.
It's not trolling, I want to speak for a better Ruby... - so
highlighting what I don't feel as 'expected';
I believe, I'm not the only one [but sure, everybody can be wrong].
So everybody can tell us his/her opinion!

_I_ believe "doing other things than expected" (like executing puts with
a block) should be telled to the programmer (warning or failure),
conceiving as a advantage.
- Practice shows that this leads to asking for the details of blocks and
hashes...
Therefore _I_ think it's okay to show up such problems to all of us.

Opti

Am 07.12.21 um 06:47 schrieb Ryan Davis:
>> On Dec 6, 2021, at 02:59, Die Optimisten <inform@die-optimisten.net> wrote:
>>
>> I'm just pointing out that 1) this is not what one would expect,
> A common error I keep seeing in your posts is to conflate what YOU do not expect with what the general public does not expect. Just because YOU do not expect it does not mean it confuses the rest of us documentation reading rubyists.
>
> And before anyone comes to their defense... They've been doing this crap for FIVE YEARS. It's all archived. This is trolling behavior.
>
>> 2) If it can't be parsed, there should be an error
> It was parsed, and correctly. There was no error. Passing a block to a method that doesn't use it is not (necessarily) an error.
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

--
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Die_Optimisten · 8 December 2021 20:19

Hi,
"Matz's principle of least surprise" - ok...
(I know, all can be achived writing a workaround)
> Given block never being called:
So - just to make my imagination broader - could you give an example, a
case, when no distinction [block or other param (hash) ] is useful?

thank you
Opti

···

Am 07.12.21 um 15:44 schrieb Austin Ziegler:

What you’re asking for is excess strictness at runtime, which would
make Ruby not Ruby. Remember that Ruby’s principle of least surprise
is better understood as "principle of Matz’s least surprise".

It is not, and should never be, an error to pass a block to a function
that doesn’t use it, in part because of Ruby’s extreme dynamism.
Trying to detect this "error" at parse time is impossible, and nothing
stops someone from doing:

module Kernel
   alias __original_puts puts
   def puts(*args)
     args = args.map { |arg| arg } if block_given?
     __original_puts(*args)
   end
end

puts "Passing a block to puts is an error" do |arg| arg.sub(/\bis\b/,
"is not" end

Stop confusing your limitation of imagination with a universal one.

-a

On Tue, Dec 7, 2021 at 8:56 AM Die Optimisten <inform@die-optimisten.net> wrote:

Hi
Yes, maybe most people are not concerned with such "special behaviours".
My opinion is that (to avoid poorly to find programming errors), that
possible errors should be shown (->throwing an error).
Besides I read (don't remember where), that it is good programing style
to check for a block.

puts has no usage of the block, so _I_ believe, there should be an error
thrown if calling with a block.
I (everyone?) would like to be able to use it [whole Ruby] "as expected"
without having the need of reading (too much) documentation, making the
language easier to use.
It's not trolling, I want to speak for a better Ruby... - so
highlighting what I don't feel as 'expected';
I believe, I'm not the only one [but sure, everybody can be wrong].
So everybody can tell us his/her opinion!

_I_ believe "doing other things than expected" (like executing puts with
a block) should be telled to the programmer (warning or failure),
conceiving as a advantage.
- Practice shows that this leads to asking for the details of blocks and
hashes...
Therefore _I_ think it's okay to show up such problems to all of us.

Opti

Am 07.12.21 um 06:47 schrieb Ryan Davis:

On Dec 6, 2021, at 02:59, Die Optimisten <inform@die-optimisten.net> wrote:

I'm just pointing out that 1) this is not what one would expect,

A common error I keep seeing in your posts is to conflate what YOU do not expect with what the general public does not expect. Just because YOU do not expect it does not mean it confuses the rest of us documentation reading rubyists.

And before anyone comes to their defense... They've been doing this crap for FIVE YEARS. It's all archived. This is trolling behavior.

2) If it can't be parsed, there should be an error

It was parsed, and correctly. There was no error. Passing a block to a method that doesn't use it is not (necessarily) an error.

Austin_Ziegler5 · 8 December 2021 20:48

I haven’t been following this thread, and I mostly don’t care about
the specific item which may have originally confused you or the
original poster.

I honestly can’t think of any regular (non-malicious) case where one
would confuse a near-binding block (`{}`) with a hash declaration
_except_ that of an empty block, and that can be handled with
parentheses.

That is, if one is trying to call `foo {} {}` (which in Ruby 2.7
results in a syntax error), one should call `foo({}) {}`. If one is
explicitly trying to pass a block as the first parameter, but _not_
the implicit block, then stop trying to use the implicit block
declaration (`foo(proc{})` or `foo(lambda{})` or `foo(->{})`.

These are not hard concepts to learn, and they should be something
that is learned by Ruby developers.

-a

···

On Wed, Dec 8, 2021 at 3:20 PM Die Optimisten <inform@die-optimisten.net> wrote:

Hi,
"Matz's principle of least surprise" - ok...
(I know, all can be achived writing a workaround)
> Given block never being called:
So - just to make my imagination broader - could you give an example, a
case, when no distinction [block or other param (hash) ] is useful?

thank you
Opti

Am 07.12.21 um 15:44 schrieb Austin Ziegler:
> What you’re asking for is excess strictness at runtime, which would
> make Ruby not Ruby. Remember that Ruby’s principle of least surprise
> is better understood as "principle of Matz’s least surprise".
>
> It is not, and should never be, an error to pass a block to a function
> that doesn’t use it, in part because of Ruby’s extreme dynamism.
> Trying to detect this "error" at parse time is impossible, and nothing
> stops someone from doing:
>
> module Kernel
> alias __original_puts puts
> def puts(*args)
> args = args.map { |arg| arg } if block_given?
> __original_puts(*args)
> end
> end
>
> puts "Passing a block to puts is an error" do |arg| arg.sub(/\bis\b/,
> "is not" end
>
> Stop confusing your limitation of imagination with a universal one.
>
> -a
>
> On Tue, Dec 7, 2021 at 8:56 AM Die Optimisten <inform@die-optimisten.net> wrote:
>> Hi
>> Yes, maybe most people are not concerned with such "special behaviours".
>> My opinion is that (to avoid poorly to find programming errors), that
>> possible errors should be shown (->throwing an error).
>> Besides I read (don't remember where), that it is good programing style
>> to check for a block.
>>
>> puts has no usage of the block, so _I_ believe, there should be an error
>> thrown if calling with a block.
>> I (everyone?) would like to be able to use it [whole Ruby] "as expected"
>> without having the need of reading (too much) documentation, making the
>> language easier to use.
>> It's not trolling, I want to speak for a better Ruby... - so
>> highlighting what I don't feel as 'expected';
>> I believe, I'm not the only one [but sure, everybody can be wrong].
>> So everybody can tell us his/her opinion!
>>
>> _I_ believe "doing other things than expected" (like executing puts with
>> a block) should be telled to the programmer (warning or failure),
>> conceiving as a advantage.
>> - Practice shows that this leads to asking for the details of blocks and
>> hashes...
>> Therefore _I_ think it's okay to show up such problems to all of us.
>>
>> Opti
>>
>>
>>
>> Am 07.12.21 um 06:47 schrieb Ryan Davis:
>>>> On Dec 6, 2021, at 02:59, Die Optimisten <inform@die-optimisten.net> wrote:
>>>>
>>>> I'm just pointing out that 1) this is not what one would expect,
>>> A common error I keep seeing in your posts is to conflate what YOU do not expect with what the general public does not expect. Just because YOU do not expect it does not mean it confuses the rest of us documentation reading rubyists.
>>>
>>> And before anyone comes to their defense... They've been doing this crap for FIVE YEARS. It's all archived. This is trolling behavior.
>>>
>>>> 2) If it can't be parsed, there should be an error
>>> It was parsed, and correctly. There was no error. Passing a block to a method that doesn't use it is not (necessarily) an error.
>>>

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

--
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

List.rb · 13 December 2021 21:37

I still have an old habit where In irb, I just prefix the 'hash' with h=
p h={'asf' => 'a' }

···

On Wed, Dec 8, 2021 at 3:49 PM Austin Ziegler <halostatue@gmail.com> wrote:

I haven’t been following this thread, and I mostly don’t care about
the specific item which may have originally confused you or the
original poster.

I honestly can’t think of any regular (non-malicious) case where one
would confuse a near-binding block (`{}`) with a hash declaration
_except_ that of an empty block, and that can be handled with
parentheses.

That is, if one is trying to call `foo {} {}` (which in Ruby 2.7
results in a syntax error), one should call `foo({}) {}`. If one is
explicitly trying to pass a block as the first parameter, but _not_
the implicit block, then stop trying to use the implicit block
declaration (`foo(proc{})` or `foo(lambda{})` or `foo(->{})`.

These are not hard concepts to learn, and they should be something
that is learned by Ruby developers.

-a

On Wed, Dec 8, 2021 at 3:20 PM Die Optimisten <inform@die-optimisten.net> > wrote:
>
> Hi,
> "Matz's principle of least surprise" - ok...
> (I know, all can be achived writing a workaround)
> > Given block never being called:
> So - just to make my imagination broader - could you give an example, a
> case, when no distinction [block or other param (hash) ] is useful?
>
> thank you
> Opti
>
> Am 07.12.21 um 15:44 schrieb Austin Ziegler:
> > What you’re asking for is excess strictness at runtime, which would
> > make Ruby not Ruby. Remember that Ruby’s principle of least surprise
> > is better understood as "principle of Matz’s least surprise".
> >
> > It is not, and should never be, an error to pass a block to a function
> > that doesn’t use it, in part because of Ruby’s extreme dynamism.
> > Trying to detect this "error" at parse time is impossible, and nothing
> > stops someone from doing:
> >
> > module Kernel
> > alias __original_puts puts
> > def puts(*args)
> > args = args.map { |arg| arg } if block_given?
> > __original_puts(*args)
> > end
> > end
> >
> > puts "Passing a block to puts is an error" do |arg| arg.sub(/\bis\b/,
> > "is not" end
> >
> > Stop confusing your limitation of imagination with a universal one.
> >
> > -a
> >
> > On Tue, Dec 7, 2021 at 8:56 AM Die Optimisten < > inform@die-optimisten.net> wrote:
> >> Hi
> >> Yes, maybe most people are not concerned with such "special
behaviours".
> >> My opinion is that (to avoid poorly to find programming errors), that
> >> possible errors should be shown (->throwing an error).
> >> Besides I read (don't remember where), that it is good programing
style
> >> to check for a block.
> >>
> >> puts has no usage of the block, so _I_ believe, there should be an
error
> >> thrown if calling with a block.
> >> I (everyone?) would like to be able to use it [whole Ruby] "as
expected"
> >> without having the need of reading (too much) documentation, making
the
> >> language easier to use.
> >> It's not trolling, I want to speak for a better Ruby... - so
> >> highlighting what I don't feel as 'expected';
> >> I believe, I'm not the only one [but sure, everybody can be wrong].
> >> So everybody can tell us his/her opinion!
> >>
> >> _I_ believe "doing other things than expected" (like executing puts
with
> >> a block) should be telled to the programmer (warning or failure),
> >> conceiving as a advantage.
> >> - Practice shows that this leads to asking for the details of blocks
and
> >> hashes...
> >> Therefore _I_ think it's okay to show up such problems to all of us.
> >>
> >> Opti
> >>
> >>
> >>
> >> Am 07.12.21 um 06:47 schrieb Ryan Davis:
> >>>> On Dec 6, 2021, at 02:59, Die Optimisten <inform@die-optimisten.net> > wrote:
> >>>>
> >>>> I'm just pointing out that 1) this is not what one would expect,
> >>> A common error I keep seeing in your posts is to conflate what YOU
do not expect with what the general public does not expect. Just because
YOU do not expect it does not mean it confuses the rest of us documentation
reading rubyists.
> >>>
> >>> And before anyone comes to their defense... They've been doing this
crap for FIVE YEARS. It's all archived. This is trolling behavior.
> >>>
> >>>> 2) If it can't be parsed, there should be an error
> >>> It was parsed, and correctly. There was no error. Passing a block to
a method that doesn't use it is not (necessarily) an error.
> >>>
>
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

--
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

List.rb · 13 December 2021 21:39

I guess p ={'asf' => 'a' } works too

···

On Mon, Dec 13, 2021 at 4:37 PM Lyst Arbey <list.rb@gmail.com> wrote:

I still have an old habit where In irb, I just prefix the 'hash' with h=
p h={'asf' => 'a' }

On Wed, Dec 8, 2021 at 3:49 PM Austin Ziegler <halostatue@gmail.com> > wrote:

I haven’t been following this thread, and I mostly don’t care about
the specific item which may have originally confused you or the
original poster.

I honestly can’t think of any regular (non-malicious) case where one
would confuse a near-binding block (`{}`) with a hash declaration
_except_ that of an empty block, and that can be handled with
parentheses.

That is, if one is trying to call `foo {} {}` (which in Ruby 2.7
results in a syntax error), one should call `foo({}) {}`. If one is
explicitly trying to pass a block as the first parameter, but _not_
the implicit block, then stop trying to use the implicit block
declaration (`foo(proc{})` or `foo(lambda{})` or `foo(->{})`.

These are not hard concepts to learn, and they should be something
that is learned by Ruby developers.

-a

On Wed, Dec 8, 2021 at 3:20 PM Die Optimisten <inform@die-optimisten.net> >> wrote:
>
> Hi,
> "Matz's principle of least surprise" - ok...
> (I know, all can be achived writing a workaround)
> > Given block never being called:
> So - just to make my imagination broader - could you give an example, a
> case, when no distinction [block or other param (hash) ] is useful?
>
> thank you
> Opti
>
> Am 07.12.21 um 15:44 schrieb Austin Ziegler:
> > What you’re asking for is excess strictness at runtime, which would
> > make Ruby not Ruby. Remember that Ruby’s principle of least surprise
> > is better understood as "principle of Matz’s least surprise".
> >
> > It is not, and should never be, an error to pass a block to a function
> > that doesn’t use it, in part because of Ruby’s extreme dynamism.
> > Trying to detect this "error" at parse time is impossible, and nothing
> > stops someone from doing:
> >
> > module Kernel
> > alias __original_puts puts
> > def puts(*args)
> > args = args.map { |arg| arg } if block_given?
> > __original_puts(*args)
> > end
> > end
> >
> > puts "Passing a block to puts is an error" do |arg| arg.sub(/\bis\b/,
> > "is not" end
> >
> > Stop confusing your limitation of imagination with a universal one.
> >
> > -a
> >
> > On Tue, Dec 7, 2021 at 8:56 AM Die Optimisten < >> inform@die-optimisten.net> wrote:
> >> Hi
> >> Yes, maybe most people are not concerned with such "special
behaviours".
> >> My opinion is that (to avoid poorly to find programming errors), that
> >> possible errors should be shown (->throwing an error).
> >> Besides I read (don't remember where), that it is good programing
style
> >> to check for a block.
> >>
> >> puts has no usage of the block, so _I_ believe, there should be an
error
> >> thrown if calling with a block.
> >> I (everyone?) would like to be able to use it [whole Ruby] "as
expected"
> >> without having the need of reading (too much) documentation, making
the
> >> language easier to use.
> >> It's not trolling, I want to speak for a better Ruby... - so
> >> highlighting what I don't feel as 'expected';
> >> I believe, I'm not the only one [but sure, everybody can be wrong].
> >> So everybody can tell us his/her opinion!
> >>
> >> _I_ believe "doing other things than expected" (like executing puts
with
> >> a block) should be telled to the programmer (warning or failure),
> >> conceiving as a advantage.
> >> - Practice shows that this leads to asking for the details of blocks
and
> >> hashes...
> >> Therefore _I_ think it's okay to show up such problems to all of us.
> >>
> >> Opti
> >>
> >>
> >>
> >> Am 07.12.21 um 06:47 schrieb Ryan Davis:
> >>>> On Dec 6, 2021, at 02:59, Die Optimisten < >> inform@die-optimisten.net> wrote:
> >>>>
> >>>> I'm just pointing out that 1) this is not what one would expect,
> >>> A common error I keep seeing in your posts is to conflate what YOU
do not expect with what the general public does not expect. Just because
YOU do not expect it does not mean it confuses the rest of us documentation
reading rubyists.
> >>>
> >>> And before anyone comes to their defense... They've been doing this
crap for FIVE YEARS. It's all archived. This is trolling behavior.
> >>>
> >>>> 2) If it can't be parsed, there should be an error
> >>> It was parsed, and correctly. There was no error. Passing a block
to a method that doesn't use it is not (necessarily) an error.
> >>>
>
>
> Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

--
Austin Ziegler • halostatue@gmail.com • austin@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>

Christian_Haase · 14 December 2021 10:18

Hi,

So - just to make my imagination broader - could you give an example, a
case, when no distinction [block or other param (hash) ] is useful?

I think about this behaviour is more of a side effect with very little
impact. I always use parenthesis around arguments in normal source code
and I think this should be the default for everyone.

The fact that parenthesis are optional is only relevant for me when
either hacking something in pry or - more important - when using DSLs.

Take this sinatra route, I think this is a good example for where
leaving out the parenthesis makes sense:

get '/hello' do
'Hello world'
end

On the other hand I would like to be able to use the {}-blocks, for
example in ARGF.each_line.map { |l| modify(l) }.join(',')

To be able to support both, and also keep the C-style curly brackets
there is this tradeoff, that you have to use func({}). Most of the cases
you want to use keyword arguments anyway, or take the hash from a
variable anyway if it is data. So I fully agree with Austins last mail.

Christian

···

--
ifu Hamburg - Member of iPoint Group
"Productivity meets Sustainability"

ifu Institut für Umweltinformatik Hamburg GmbH
Max-Brauer-Allee 50 - 22765 Hamburg - Germany
fon: +49 40 480009-0 - fax: +49 40 480009-22 - email: info@ifu.com

Managing Director: Jan Hedemann - Commercial Register: Hamburg, HRB 52629
www.ifu.com - www.umberto.de - www.e-sankey.com

Topic		Replies	Views
Begineer question ruby-talk	8	76	20 May 2007
Beginner question ruby-talk	4	92	18 May 2007
General newbie qustion ruby-talk	8	101	2 October 2012
Why this code is working ruby-talk	2	111	18 April 2008
Block delimiting ruby-talk	0	59	9 January 2004

definitively a bug

Related Topics