If you consider this as a bug, why don't file on a report yourself?
Hello
First we should discuss it.
ok -> How can I submit a bug / feature|change request?
Opti
···
Am 11.08.22 um 18:29 schrieb Der Zernichter:
If you consider this as a bug, why don't file on a report yourself?
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
But you wont anyone let convince you otherwise anyway, will you?
For my the return of nil is enough: it doesnot behave like an array an any
code using the result will crash with a reasonable error message. Sounds
like a pragmatic solution me
···
Die Optimisten <inform@die-optimisten.net> schrieb am Do., 11. Aug. 2022, 19:25:
Hello
First we should discuss it.
ok -> How can I submit a bug / feature|change request?
OptiAm 11.08.22 um 18:29 schrieb Der Zernichter:
If you consider this as a bug, why don't file on a report yourself?
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe> <ruby-talk-request@ruby-lang.org?subject=unsubscribe><http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk> <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>
The beauty of Ruby: Make you own damn array:
class OptiArray < Array
def (a, b=nil)
return super(a) if b.nil?
(a...a + b).map{|i| super(i)}
end
end
a = OptiArray.new([1,2,3,4,5]) #=> [1, 2, 3, 4, 5]
a[-10,10] #=> [nil, nil, nil, nil, nil, 1, 2, 3, 4, 5]
Create an account at https://bugs.ruby-lang.org/ and open an issue. Be as
detailed as possible with your description. Include some examples.
Be aware that if you propose something backward incompatible it will likely
be rejected. The Ruby developers prize backward compatibility, so try to
propose an extension of the current behavior, such as by creating a new
method with all of your desired behavior.
-Jeremy
···
On Thu, Aug 11, 2022 at 12:25 PM Die Optimisten <inform@die-optimisten.net> wrote:
Hello
First we should discuss it.
ok -> How can I submit a bug / feature|change request?
Hi,
no, I want to be confirmed, that the existing is better than what I want!
But I also agree that a[any_range] should be == any_range.map {|i|
a.fetch(i,nil) } #filled up with nils
So there should always be an array returned (my optinion!)
If not wanting that an (specific) error should be thrown (range below
beginning, range above end, range has no elements [x,0], etc...)
How can I submit to the developers (list) ?
Opti
···
Am 11.08.22 um 19:30 schrieb Der Zernichter:
But you wont anyone let convince you otherwise anyway, will you?
For my the return of nil is enough: it doesnot behave like an array an
any code using the result will crash with a reasonable error message.
Sounds like a pragmatic solution meDie Optimisten <inform@die-optimisten.net
<mailto:inform@die-optimisten.net>> schrieb am Do., 11. Aug. 2022, 19:25:Hello
First we should discuss it.
ok -> How can I submit a bug / feature|change request?
Opti
Hello!
a=; a[10]=10 # also fills [0..9] with nils, so arrays are
"extended" automatically.
(and hopefully not consuming RAM for each element?
( so a=; a[1]=1 would consume much less Ram than a=; a[Mio]=1 ?? )
Therefore the _result_ should also be extended, when extending the range.
If unintended, then fetch should be used.
Sb having an account on the bugs-list already?
Please submit Array.fetch(obj | range | index, count)
Opti
-> CORRECTED: array/enum.fetch( index[int] | range | index, count
[,default: not_found_default | not_found_proc] ) { |element| block }
\-> returns: obj for index \# compatibility
array/enum for using the other forms\.
Opti
···
Am 12.08.22 um 11:50 schrieb Die Optimisten:
Hello!
a=; a[10]=10 # also fills [0..9] with nils, so arrays are
"extended" automatically.
(and hopefully not consuming RAM for each element?
( so a=; a[1]=1 would consume much less Ram than a=; a[Mio]=1 ?? )
Therefore the _result_ should also be extended, when extending the range.
If unintended, then fetch should be used.
Sb having an account on the bugs-list already?
Please submit Array.fetch(obj | range | index, count)
Hello!
a=; a[10]=10 # also fills [0..9] with nils, so arrays are
"extended" automatically.
(and hopefully not consuming RAM for each element?
( so a=; a[1]=1 would consume much less Ram than a=; a[Mio]=1 ?? )
Therefore the _result_ should also be extended, when extending the
range.
If unintended, then fetch should be used.
Sb having an account on the bugs-list already?
Please submit Array.fetch(obj | range | index, count)
-> CORRECTED: array/enum.fetch( index[int] | range | index, count
[,not_found: not_found_default | not_found_proc] ) { |element| block }
YES, the block-argument is not incompatible (the opposite of ...) to the
previous task 
- But much better! -> so we need a new name for that method?
···
Am 12.08.22 um 11:58 schrieb Die Optimisten:
Am 12.08.22 um 11:50 schrieb Die Optimisten:
-> returns: obj for index # compatibility
array/enum for using the other forms.Opti
Hello!
a=; a[10]=10 # also fills [0..9] with nils, so arrays are
"extended" automatically.
(and hopefully not consuming RAM for each element?
( so a=; a[1]=1 would consume much less Ram than a=; a[Mio]=1 ?? )
Therefore the _result_ should also be extended, when extending the
range.
If unintended, then fetch should be used.
Sb having an account on the bugs-list already?
Please submit Array.fetch(obj | range | index, count)
-> CORRECTED: array/enum.fetch( index[int] | range | index, count
[,not_found: not_found_default | not_found_proc] ) { |element| block }
YES, the block-argument is very incompatible (the opposite of ...) to
the previous task
- But much better! -> so we need a new name for that method?
···
Am 12.08.22 um 11:58 schrieb Die Optimisten:
Am 12.08.22 um 11:50 schrieb Die Optimisten:
-> returns: obj for index # compatibility
array/enum for using the other forms.Opti
Sorry, this is getting too cryptic for me. Cannot comment in this
For me the current behaviour is fine: return nil instead of an exception.
···
Die Optimisten <inform@die-optimisten.net> schrieb am Fr., 12. Aug. 2022, 12:10:
Am 12.08.22 um 11:58 schrieb Die Optimisten:
> Am 12.08.22 um 11:50 schrieb Die Optimisten:
>> Hello!
>> a=; a[10]=10 # also fills [0..9] with nils, so arrays are
>> "extended" automatically.
>> (and hopefully not consuming RAM for each element?
>> ( so a=; a[1]=1 would consume much less Ram than a=; a[Mio]=1 ?? )
>> Therefore the _result_ should also be extended, when extending the
>> range.
>> If unintended, then fetch should be used.
>> Sb having an account on the bugs-list already?
>> Please submit Array.fetch(obj | range | index, count)
-> CORRECTED: array/enum.fetch( index[int] | range | index, count
[,not_found: not_found_default | not_found_proc] ) { |element| block }YES, the block-argument is very incompatible (the opposite of ...) to
the previous task
- But much better! -> so we need a new name for that method?> -> returns: obj for index # compatibility
> array/enum for using the other forms.
>
> OptiUnsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>