Confusion with `nil` value being produced by IRB in case of Array#size manipulation

enum[int] = obj → obj
enum[start, length] = obj → obj
enum[range] = obj → obj

During my reading and understandding with the above I tried something in
my IRB as below:

a = []

=> []

a.size

=> 0

Humm, understood. As no element I still added.

a[0]

=> nil

a[1]

=> nil

as the array size is 0, while trying to access the a[1] getting no
exception - why so? that means index is there or what?
what logic does help IRB to show such nil values?

a[1] = 5

=> 5

a

=> [nil, 5]

The above code what should I say - new value addition or substitution of
‘nil’?

a.size

=> 2

Okay! so now the size is 2.

Now in the below as the size is 2 thus a[3] is showing nil.
a[3] <~~~~ point - I

=> nil

a.size

=> 2

Now I added nil in the same index intentionaly. And the size got
changed to 3.

a[3] = nil

=> nil

a.size

=> 3

a[3] <~~~~ point - II

=> nil

What is the difference between the output of a[3] in point- I and point
-II ?
Why does both nil value being treated differently as mentioned above?

Have you even tried to read the documentation???
Did you ever read any tutorial or introductory book???

Please stop posting your “experiments”. READ THE DOCS.

AGAIN: READ. THE. DOCS!!! READ. SOME. BOOK!!!

Am 24.02.2013 10:45, schrieb Love U Ruby:

=> 0

what logic does help IRB to show such nil values?
READ THE DOCS.

a[1] = 5

=> 5

a

=> [nil, 5]

The above code what should I say - new value addition or substitution of
‘nil’?

READ THE DOCS.

Now I added nil in the same index intentionaly. And the size got
changed to 3.

OF COURSE.

unknown wrote in post #1098721:

Have you even tried to read the documentation???
Did you ever read any tutorial or introductory book???

You really don’t have the brain to understand my question. And you
should try to read the DOC you might get the answers from there. I
didn’t get. This is not a simple question,it is conceptual. Why should I
not express such conceptual things to the outer world.

DO YOU THINK HERE THE COMMUNITY EXPERTS ARE ONLY TO HELP YOU TO DEVELOP
YOUR INDUSTRY SOFTWARE?

This post is not like that personal, it is common for all Ruby lover.

BTW when books already mentioned that if any confusion to ask in mailing
list, who are you to STOP me NON-SENSE?

unknown wrote in post #1098725

No sir. :slight_smile: this is not my answer. Please wait hope someone would catch
my point and would answer to my specific question.

Element Assignment—Sets the element at index, or replaces a
subarray starting at start and continuing for length
elements, or replaces a subarray specified by range.
If indices are greater than the current capacity of the array, the
array grows automatically.

[…]

a = Array.new
a[4] = “4”; #=> [nil, nil, nil, nil, “4”]

Arup / Love U / Xavier:

Offending list members will not help you at all.
Instead, you should go away and learn reading (take your time).
The come back and read this:

= Array.[]

(from ruby site)

[…]

Element Reference—Returns the element at index, or returns a
subarray starting at start and continuing for length
elements, or returns a subarray specified by range. Negative indices
count backward from the end of the array (-1 is the last element).
Returns nil if the index (or starting index) are out of range.


= Array.[]=

(from ruby site)

[…]

Element Assignment—Sets the element at index, or replaces a
subarray starting at start and continuing for length
elements, or replaces a subarray specified by range.
If indices are greater than the current capacity of the array, the
array grows automatically.

[…]

a = Array.new
a[4] = “4”; #=> [nil, nil, nil, nil, “4”]

Hans M. wrote in post #1098729:

its because ruby does not make a difference in Array#[] if the element
is nil or non existendt …

array = [nil]
array[0] #=> nil

array[1] #=> nil

see? there is no difference and no error!

Humm @Hans-

I just noticed one point which is that, whenever Ruby finds an index
which is “out of index” , instead throwing an exception it only prints
nil.But yes it is the case only when we are reading the element from
an index which is still not present in the array.

Am 24.02.2013 13:26, schrieb Love U Ruby:

Humm @Hans-

I just noticed one point which is that, whenever Ruby finds an index
which is “out of index” , instead throwing an exception it only prints
nil.But yes it is the case only when we are reading the element from
an index which is still not present in the array.

“Just noticed” … you really must be kidding.

This is exactly what is stated in the part of the documentation
that I cited in my previous post, and even emphasized with stars (*),
so that you could find it more easily. Here it is again:

“Returns nil if the index (or starting index) are out of range.”

Note also that Ruby does not “print” nil, Array#[] returns nil
in that case.

Next time, before insulting other people and making a complete fool
out of yourself, do your research and reading more carefully.

unknown wrote in post #1098771:

Am 24.02.2013 13:26, schrieb Love U Ruby:

Humm @Hans-

Sorry! I might skipped that part. apologies for that.

This is exactly what is stated in the part of the documentation
that I cited in my previous post, and even emphasized with stars (*),
so that you could find it more easily. Here it is again:

“Returns nil if the index (or starting index) are out of range.”

Note also that Ruby does not “print” nil, Array#[] returns nil
in that case.

Next time, before insulting other people and making a complete fool
out of yourself, do your research and reading more carefully.

its because ruby does not make a difference in Array#[] if the element
is nil or non existendt …

array = [nil]
array[0] #=> nil

array[1] #=> nil

see? there is no difference and no error!

Am 24.02.2013 15:22, schrieb Love U Ruby:

Sorry! I might skipped that part. apologies for that.

Well… why should I (or many others in this list) ever answer a
question of you again? You ignore our advice and read neither the
documentation nor one of the many good introductory tutorials or books
(yet ask about books on metaprogramming… what a joke!),
you do not even read our answers but instead insult us and our mental
capability to grasp the “deeper” meaning of your silly questions.

Think about that.

No reply necessary.