Forum: Ruby 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?

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

unknown wrote in post #1098725
>

No sir. :) 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"]

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!

Hans Mackowiak 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.

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.