Re: Hash

ruby-talk
21

Hi
I thought this list is for discussing Ruby including its "strange"
things (doing things which are not intended) - we don't want to speak
about a=b+1)
- Do you disagree implementing a warning when changing defaults by using
a normal key?
I believe when that occurs, then in most cases it's NOT intended.
Thanks for 1) and 2); I just answered that many times because of being
totally misunderstood,
Regarding friendliness, Ziegler used the wrong words. - Sorry, that's
completely out of the place.
Opti

···

Am 08.06.22 um 18:48 schrieb Jack Royal-Gordon:

I have to agree with Austin here. Die, I’ve generally stopped reading
your emails to this group (unless I’m in a mood to be frustrated),
because I know that you’re going to take some simple feature, do
something odd with it, and then complain about the results. And then,
when some well-intentioned reader tries to explain why what you’re
doing is not appropriate, you argue with them.

Austin is right that *every* programming language will have some
obtuse features. Assuming that you are really trying to accomplish
what you say you want to do, instead of insisting that it should work
the way you want it to, do one of two things:

1) Find out the “right” way to do it (there is often more than one,
and different users may disagree on the right way, so find a way that
works and makes sense to **you**).

2) Realize that maybe what you’re trying to do is not a good fit for
the feature you’re trying to use and find a different feature to do it
with. For example, it’s good practice to avoid using integers as Hash
keys, simply because of the similarities between the syntax for a Hash
key and and an Array index. Violate this principle at your own risk.

Further, it’s one thing to explore a feature, find what appears to be
inconsistent behavior and point it out. It’s quite another thing, when
others on this list invest their precious time responding to your
post, to insult them by arguing (which you seem to do every time).
Please recognize that if someone who responds to you really gives a
poor argument or tells you something incorrect, someone else will
definitely correct them.

I don’t normally respond to these sorts of occurrences, but you’ve
been doing this for so long that I'm really tired of seeing it. Please
stop!

On Jun 8, 2022, at 7:59 AM, Austin Ziegler <halostatue@gmail.com >> <mailto:halostatue@gmail.com>> wrote:

    As I wrote, it's about the (strange - not coherent/consistent)
    "syntax"
    you have to use to get what you want. I pointed out, that for
    Array it
    is again another form.

Just stop. You have been trolling this mailing list for years,
convinced that your view is the only correct view of Ruby and
refusing to accept any mental model except your own. If, indeed, you
actually know C, then you know that there’s places in C syntax where
consistency simply doesn’t exist, as is the case with *any*
programming language. Each and every instance of UB is a lack of
consistency and clarity where one is invited to mess around and find
out what your compiler does, because every compiler will do it
differently.

In comparison, Ruby object instantiation is crystal clear *and*
well-documented. Just because you can’t accept that the semantics are
foreign *to you* does not make them surprising, unobvious, or
anything except "foreign to you".

Let’s try to provide some education to readers of the thread, even
though it will obviously not be you.

    But (very) surprising for me is that h=Hash.new(); h[1] << 1 # we
    should at least get a warning if changing the defaultval; nobody
    expects after changing h[1], that (the key) h[1] does not exist,
    although it's clear when understanding what is done.

Variables in Ruby are not locations. They are labels. In C, the
expression `uint32_t a = b = 3` takes up approximately 8 bytes of
stack memory. In Ruby, the expression `a = b = 3` takes up
approximately one Object of memory (certain numbers are special in
most implementations of Ruby, but that is an implementation detail
about most numbers being "internalized").

Variables in Ruby are labels to *references* (to objects).
Expressions in Ruby return *references* (to objects). With this
minimal information, it becomes pretty easy to reason that `h =
Hash.new()` gives me a reference to the Hash which I have labeled
`h`. If I don’t understand why `h[1] << 1` modifies `h.default`, then
I read some documentation and realize that even if I do `h[1]`, that
does not necessarily mean `h.has_key?(1)` returns true because I
provided a mutable default object. Or I could even see
`h[1].object_id == h[2].object_id` returning a true value, and
enlightenment might actually occur.

I might actually then be able to reason that `h[1] == h.default`
because I’m really dealing with object references all the way down so
that when I modify `h[1]` because `h.has_key?(1) == false`, I’m
really modifying `h.default`. This isn’t something that would occur
to a C genius, of course, because reading the fine manual would
disabuse said genius of their ability to troll people on the same or
similar topics again, and again, and again.

-a
--
Austin Ziegler • halostatue@gmail.com <mailto:halostatue@gmail.com> •
austin@halostatue.ca <mailto: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&gt;

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

22

How would you implement such a warning? The default value of a Hash does
not know that it’s the default value of a Hash, so there’s nothing that any
implementation of Ruby could do in order to track this inane request. If
you had listened to any *one* of a number of respondents, you would have
been able to figure this out. Understand that these lines are functionally
equivalent:

d = []
h = Hash.new(d)

d << 1
h[1] << 1

It’s obvious that `Hash.new(default_value)` doesn’t do what *you* expect,
but the first thing you do is come in trolling the list saying "Ruby is
wrong! Ruby is wrong! Change Ruby!". The first thing you should have done
is, instead, read the documentation of the API that you’re trying to use.
If I complain that JavaScript is wrong because `"" == 0` and demand that
*everyone* bow to my demand that `"" == 0` should be an error, then I’m
simply being a troll. Or Die Optimisten, same thing.

That which you find "strange" is probably not (and in this case, is
trivially shown to be not) and is, in all likelihood, intended by the
implementers of the interpreters of Ruby. When I ran into this issue twenty
years ago (when I started learning Ruby), I didn’t immediately assume that
I was right and Ruby was wrong (I had *different* places of arrogance,
thinking that nil != nil should be true and nil == nil should be false). I
looked at the documentation (much sparser back in 2002 than in 2022) and I
was enlightened. Or I asked real questions and learned from the answers.

Please don’t assume that we misunderstood you. We absolutely do understand
you and your methods, and I, for one, have had enough of your trolling.
You’re not actually wanting to learn Ruby, and your methods make it harder
for people who do want and need help to find useful information from this
mailing list. Friendliness is important, but so is frankness. To be frank,
you’re wasting our time.

-a

···

On Wed, Jun 8, 2022 at 1:14 PM Die Optimisten <inform@die-optimisten.net> wrote:

I thought this list is for discussing Ruby including its "strange" things
(doing things which are not intended) - we don't want to speak about a=b+1)
- Do you disagree implementing a warning when changing defaults by using a
normal key?

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

23

[text inserted between paragraphs]

    I thought this list is for discussing Ruby including its "strange"
    things (doing things which are not intended) - we don't want to
    speak about a=b+1)
    - Do you disagree implementing a warning when changing defaults by
    using a normal key?

How would you implement such a warning? The default value of a Hash
does not know that it’s the default value of a Hash, so there’s
nothing that any implementation of Ruby could do in order to track
this inane request. If you had listened to any /one/ of a number of
respondents, you would have been able to figure this out. Understand
that these lines are functionally equivalent:

d = []
h = Hash.new(d)

d << 1
h[1] << 1

It’s obvious that `Hash.new(default_value)` doesn’t do what *you*
expect, but the first thing you do is come in trolling the list saying
"Ruby is wrong! Ruby is wrong! Change Ruby!". The first thing you
should have done is, instead, read the documentation of the API that
you’re trying to use. If I complain that JavaScript is wrong because
`"" == 0` and demand that *everyone* bow to my demand that `"" == 0`
should be an error, then I’m simply being a troll. Or Die Optimisten,
same thing.

YOU are carrying on, can't leave it...
I thought - meanwhile you were understanding - NO, I expect that
Hash.new(default) is doing what it should do. - So again: you're the die
who is trolling! - again and again. I want to speak about the technical
thinks! I said it before: I know the documentation (see my first mail
for this thread!) - SOME parts are not as anybody would expect. - I'm
not demanding anything, I tell how I see it, and suggest implementing a
warning, because I know such basic things can't be easily changed.

You're not learning - you are offending again! - So I'm voting for
banning YOU.

The warning could be easily implemented when accessing h[key]:
d = h.default; do_it_as_normal; warn(...) if d != h.default

That which you find "strange" is probably not (and in this case, is
trivially shown to be not) and is, in all likelihood, intended by the
implementers of the interpreters of Ruby. When I ran into this issue
twenty years ago (when I started learning Ruby), I didn’t immediately
assume that I was right and Ruby was wrong (I had *different* places
of arrogance, thinking that nil != nil should be true and nil == nil
should be false). I looked at the documentation (much sparser back in
2002 than in 2022) and I was enlightened. Or I asked real questions
and learned from the answers.

Ok, you had another approach than I have. If you were thinking nil!=nil
it's fine that you're enlightened.

Please don’t assume that we misunderstood you.

So why do you then write "It’s obvious that `Hash.new(default_value)`
doesn’t do what *you* expect" some lines above?? Apparently YOU DON'T
understand my issue till now!

We absolutely do understand you and your methods, and I, for one, have
had enough of your trolling. You’re not actually wanting to learn
Ruby, and your methods make it harder for people who do want and need
help to find useful information from this mailing list. Friendliness
is important, but so is frankness. To be frank, you’re wasting our time.

For sure, if you are not capable in any direction [insulting again and
again, and tecnically] (sorry), it's wasted time for all, including you.
- I can't stand being insulted with every new mail from you!!!
So please, mailadmins, please look at these mails and tell us your
perception.
- I feel insulted from Ziegler, it's not appropriate getting personal.

Opti

···

Am 08.06.22 um 20:02 schrieb Austin Ziegler:

On Wed, Jun 8, 2022 at 1:14 PM Die Optimisten > <inform@die-optimisten.net <mailto:inform@die-optimisten.net>> wrote:

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

24

I think you may have misunderstood Austin's example, or maybe I
misunderstand yours because I don't think your suggestion can work. Your
idea of emitting a warning isn't a bad one though. Ruby warns about
surprising behavior in other places after all.

Can you patch the following overly simplified "hash" implementation to emit
a warning?

class WarningHash
  def initialize(default)
    @default = default
  end

  def [](key)
    @default
  end
end

default = []
warning_hash = WarningHash.new(default)
warning_hash[1] << 1       # <-- This should warn.

There's also the option of submitting a patch to Ruby itself. The
interpreter may be where such a warning would need to be implemented rather
than in the implementation of Hash. A concrete implementation would be
much easier to discuss in any case.

···

On Thu, Jun 9, 2022 at 1:39 AM Die Optimisten <inform@die-optimisten.net> wrote:

[text inserted between paragraphs]

Am 08.06.22 um 20:02 schrieb Austin Ziegler:

On Wed, Jun 8, 2022 at 1:14 PM Die Optimisten <inform@die-optimisten.net> > wrote:

- Do you disagree implementing a warning when changing defaults by using
a normal key?

How would you implement such a warning? The default value of a Hash does
not know that it’s the default value of a Hash, so there’s nothing that any
implementation of Ruby could do in order to track this inane request. If
you had listened to any *one* of a number of respondents, you would have
been able to figure this out. Understand that these lines are functionally
equivalent:

d = []
h = Hash.new(d)

d << 1
h[1] << 1

The warning could be easily implemented when accessing h[key]:

  d = h.default; do_it_as_normal; warn(...) if d != h.default

25

Hi,

Can you patch the following overly simplified "hash" implementation to emit a warning?

class WarningHash
  def initialize(default)
    @default = default
  end

  def [](key)
    @default
  end
end

default = []
warning_hash = WarningHash.new(default)
warning_hash[1] << 1       # <-- This should warn.

Suppose the user doesn't understand how using a mutable object as a default value for an Hash behaves (in fact how passing mutable objects to methods behaves in Ruby) and you want to warn them. Doing so when they are modifying it means modifying each and every way that these mutable objects are modified to output a warning if they are currently used as a default for an Hash (Array#<< is one, what about String#<<, String#gsub! or even Class.include... ?). Nothing prevents anybody from using a class as a default value and nothing prevents modifying it after. What about redefining a method on an instance with def <instancename>.method... ?
Talk about an implementation nightmare.

Parameter passing in Ruby uses references to objects, not copies. If users didn't learn this before trying to set a default value for an Hash instance they'll have to eventually. This is as good a point as any in their learning process.

For reference this behavior has existed for ages : the very first version I used - 1.8.x, nearly 19 years ago - is documented to do so. This is surprising for beginners and it is fine : beginners are meant to be surprised sometimes as no language can be intuitive for everyone. I know I have stumbled upon this behavior a long time ago, was surprised, read the doc and got a deeper understanding of the language from the experience.
It is even my opinion that if seasoned developers aren't ever surprised they might be a bit too complacent and are neglecting their knowledge by not looking enough at new tools or tool versions to learn.

Note that technically you could relatively easily output a warning in Hash#initialize when a mutable object is passed but it seems completely overkill for a well-documented and very old feature of the language (and will probably annoy quite a few users actively using this feature when upgrading).

Note that answering people behaving as trolls only feeds them : in my opinion Die Optimisten is a repeat offender so I won't respond directly to this person until I see a positive change.
I even hesitated answering indirectly but the difference between emitting the warning when affecting the object as default and modifying it seemed an interesting technical point to discuss.

Best regards,

···

Le 09/06/2022 à 14:53, Jeremy Bopp a écrit :

--
Lionel Bouton
gérant de JTEK SARL
https://www.linkedin.com/in/lionelbouton/

26

Can you patch the following overly simplified "hash" implementation to
emit a warning?

class WarningHash
  def initialize(default)
    @default = default
  end

  def [](key)
    @default
  end
end

default = []
warning_hash = WarningHash.new(default)
warning_hash[1] << 1       # <-- This should warn.

It *might* be possible to build something that does this using tracepoints

(
Exploring TracePoint in Ruby — Part One — Example Code | by Brandon Weaver | Medium)
or a similar new feature, but the likelihood is low, the complexity is
high, and the performance hit would be atrocious. The fundamental mistake
that Our Resident Troll has made in its repeated recitation of inanity is
this:

The modification is happening on an object that has no knowledge of its
containing context.

The Array object instance passed in `Hash.new()` does not know that it
"belongs" to the Hash object instance. Some sort of pseudo-code for this
would have to be:

class Hash
  def [](key)
    if has?(key)
      _get(key)
    elsif default_proc
      default_proc.(self, key)
    elsif default
      pragma_warn_if_mutated(default) # THIS IS PURE D.O. TROLL MAGIC
    end
  end
end

*Somehow*, the `h.default` value would need to be wrapped *invisibly* in a
way that warns if it’s mutated.

Suppose the user doesn't understand how using a mutable object as a
default value for an Hash behaves (in fact how passing mutable objects to
methods behaves in Ruby) and you want to warn them. Doing so when they are
modifying it means modifying each and every way that these mutable objects
are modified to output a warning if they are currently used as a default
for an Hash (Array#<< is one, what about String#<<, String#gsub! or even
Class.include... ?). Nothing prevents anybody from using a class as a
default value and nothing prevents modifying it after. What about
redefining a method on an instance with def <instancename>.method... ?
Talk about an implementation nightmare.

Mmm. This is the *exact* same lesson one has to learn when doing

a = b = []
a << 1
b == [] # => false

Yes, it’s at one or two removes when passing such an object as a default
for a Hash, but value-by-reference should be one of the very *first* things
learned when programming Ruby. It’s precisely why:

def double(a)
  a = a * 2
end

a = 1
double(a)
p a # => 1

works the way that it works.

For reference this behavior has existed for ages : the very first version I

used - 1.8.x, nearly 19 years ago - is documented to do so. This is
surprising for beginners and it is fine : beginners are meant to be
surprised sometimes as no language can be intuitive for everyone. I know I
have stumbled upon this behavior a long time ago, was surprised, read the
doc and got a deeper understanding of the language from the experience.
It is even my opinion that if seasoned developers aren't ever surprised
they might be a bit too complacent and are neglecting their knowledge by
not looking enough at new tools or tool versions to learn.

I believe that 1.6.6 was my first Ruby, and it worked that way then, too.

Note that technically you could relatively easily output a warning in

Hash#initialize when a mutable object is passed but it seems completely
overkill for a well-documented and very old feature of the language (and
will probably annoy quite a few users actively using this feature when
upgrading).

That’s not a *horrible* idea to add as an optional warning flag (off by
default). What sort of class of warnings might be "beginner" warnings so
that on modern versions of Ruby, you might be able to do something like:

Warning[:beginner] = true

Which would enable a new category of warnings intended for rank beginners
or ignorant trolls. module Warning - Documentation for Ruby 3.3

-a

···

On Thu, Jun 9, 2022 at 10:02 AM Lionel Bouton <lionel.bouton@jtek.fr> wrote:

Le 09/06/2022 à 14:53, Jeremy Bopp a écrit :

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

27

It *might* be possible to build something that does this using
tracepoints
(Exploring TracePoint in Ruby — Part One — Example Code | by Brandon Weaver | Medium)
or a similar new feature, but the likelihood is low, the complexity is
high, and the performance hit would be atrocious. => The fundamental
mistake that Our Resident Troll has made in its repeated recitation of
inanity is this ... <=

1) Ziegler, STOP THAT! - Why these words again? You're an asshole!

2) you're wrong concerning the content:
It's not neccessary knowing whom it belongs to.
If the default is changed (=other than before, maybe you need a deep
copy to check that), than warn, if using h[key]=... (which normally
should not be used change the default)

···

Am 09.06.22 um 16:40 schrieb Austin Ziegler:

On Thu, Jun 9, 2022 at 10:02 AM Lionel Bouton <lionel.bouton@jtek.fr > <mailto:lionel.bouton@jtek.fr>> wrote:

The modification is happening on an object that has no knowledge of
its containing context.

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

28

It *might* be possible to build something that does this using

tracepoints (
https://medium.com/@baweaver/exploring-tracepoint-in-ruby-part-one-example-code-2cf9b1a1b956)
or a similar new feature, but the likelihood is low, the complexity is
high, and the performance hit would be atrocious. => The fundamental
mistake that Our Resident Troll has made in its repeated recitation of
inanity is this ... <=

1) Ziegler, STOP THAT! - Why these words again? You're an asshole!

There’s an easy way to no longer be named a troll: stop trolling.
Unfortunately, you can’t appear to do so based on several years of evidence
on ruby-talk. Here’s a hint: most people don’t want to be called by their
surname only. We aren’t Jack Reacher. Another hint: stop trolling.

2) you're wrong concerning the content:
It's not neccessary knowing whom it belongs to.
If the default is changed (=other than before, maybe you need a deep copy
to check that), than warn, if using h[key]=... (which normally should not
be used change the default)

"you need a deep copy to check that"

Now I know beyond a shadow of a doubt that you’re trolling, because you’re
talking about something that has orders of magnitude worse performance and
memory characteristics. Also…`default` is non-reentrant (I know that’s a
big word).

Your continuously inane example (warn if `h[1] << 1` happens) requires that
all implementations know whenever the value returned by `h[1]` is modified
as long as `h[1]` is returning `h.default`. Let’s be absolutely clear just
how *stupid* this request is:

a = []
h = Hash.new(a)
a << 1 # should warn, right? If not, then what’s the point?
b = h[1]
b << 1 # should warn, right? If not, then what’s the point?
c = a
c << 1 # should warn, right? If not, then what’s the point?
h[1] << 1 # should warn, right?

Under no circumstances does the modification of the Array instance
initially labeled `a` have *any* knowledge that it should be immutable
because it’s held by `h.default`.

This isn’t rocket science or MRNA vaccine creation, it’s Ruby. Ten minutes
of you actually *thinking* about this would point out just how *bonkers*
this concept of yours is, and you might not actually bother the list with
something this inane again. Unless, of course, you are a Troll.

What you are suggesting is (a) not possible, (b) not worth the time
invested already to convince you of this, and (c) a solid effort at
solidifying your reputation as a Troll.

I’ve engaged you because seeing your continued trolling time after time
after time has finally pissed me off enough to say something. Henceforth,
you are Die Schädlinge.

-a

···

On Thu, Jun 9, 2022 at 3:20 PM Die Optimisten <inform@die-optimisten.net> wrote:

Am 09.06.22 um 16:40 schrieb Austin Ziegler:
On Thu, Jun 9, 2022 at 10:02 AM Lionel Bouton <lionel.bouton@jtek.fr> > wrote:

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

29

    It *might* be possible to build something that does this using
    tracepoints
    (Exploring TracePoint in Ruby — Part One — Example Code | by Brandon Weaver | Medium)
    or a similar new feature, but the likelihood is low, the
    complexity is high, and the performance hit would be atrocious.
    => The fundamental mistake that Our Resident Troll has made in
    its repeated recitation of inanity is this ... <=

    1) Ziegler, STOP THAT! - Why these words again? You're an asshole!

There’s an easy way to no longer be named a troll: stop trolling.
Unfortunately, you can’t appear to do so based on several years of
evidence on ruby-talk. Here’s a hint: most people don’t want to be
called by their surname only. We aren’t Jack Reacher. Another hint:
stop trolling.

ANOTHER WAY would be you leave such messages out, or (better) you leave.
You're the only person dong that. You're the troll. You will never
understand it; die.

    2) you're wrong concerning the content:
    It's not neccessary knowing whom it belongs to.
    If the default is changed (=other than before, maybe you need a
    deep copy to check that), than warn, if using h[key]=... (which
    normally should not be used change the default)

"you need a deep copy to check that"

Now I know beyond a shadow of a doubt that you’re trolling, because
you’re talking about something that has orders of magnitude worse
performance and memory characteristics. Also…`default` is
non-reentrant (I know that’s a big word).

In most cases default is not large, so it's not a problem. Besides don't
use Ruby for performance.

Your continuously inane example (warn if `h[1] << 1` happens) requires
that all implementations know whenever the value returned by `h[1]` is
modified as long as `h[1]` is returning `h.default`. Let’s be
absolutely clear just how *stupid* this request is:

a = []
h = Hash.new(a)
a << 1 # should warn, right? If not, then what’s the point?
b = h[1]
b << 1 # should warn, right? If not, then what’s the point?
c = a
c << 1 # should warn, right? If not, then what’s the point?
h[1] << 1 # should warn, right?

VERY WRONG! Who is telling this? Yes, it's YOUR example and it's stupid!

I said: "warn if h[key] is being accessed (changed). That means (only):
h[key] is set or changed. You can check this with this only one method: .

So forget the rest you've written. It's not worth the time. All the
thumb examples are yours!

Under no circumstances does the modification of the Array instance
initially labeled `a` have *any* knowledge that it should be immutable
because it’s held by `h.default`.

This isn’t rocket science or MRNA vaccine creation, it’s Ruby. Ten
minutes of you actually *thinking* about this would point out just how
*bonkers* this concept of yours is, and you might not actually bother
the list with something this inane again. Unless, of course, you are a
Troll.

You're trapped by your limited thoughts. Not coming beyond your nose.
And always the same.

It's also YOUR wording you're using all the time. Therefore people feel
bad when reading these mails.

What you are suggesting is (a) not possible, (b) not worth the time
invested already to convince you of this, and (c) a solid effort at
solidifying your reputation as a Troll.

Yes, you again and again tell us your (wrong) view. - You didn't check it.
Looks you're mentally limited. How often again? The next 50 mails?

I’ve engaged you because seeing your continued trolling time after
time after time has finally pissed me off enough to say something.
Henceforth, you are Die Schädlinge.

OK - please ban Ziegler. It's enough of his insulting! (Sorry that I
assimilate my mode of expression being not very nice, but he deserves it!)

Opti

···

Am 09.06.22 um 22:06 schrieb Austin Ziegler:

On Thu, Jun 9, 2022 at 3:20 PM Die Optimisten > <inform@die-optimisten.net <mailto:inform@die-optimisten.net>> wrote:
    Am 09.06.22 um 16:40 schrieb Austin Ziegler:

    On Thu, Jun 9, 2022 at 10:02 AM Lionel Bouton >> <lionel.bouton@jtek.fr <mailto:lionel.bouton@jtek.fr>> wrote:

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

30

It is possible to call Hash.new in such a way:

h = Hash.new(.freeze)

Since you declared here to be immutable, it will raise once you try to modify the default value.

Unfortunately, since Ruby is an established language, a change that for example freezes the default value by default is possible, but will come to a lot of maintenance related hurdles to people who currently have very large applications developed. Surely, having it deployed though, will most probably find a lot of hard to discover bugs creeping in those codebases.

···

On 6/10/22 01:09, Die Optimisten wrote:

I said: "warn if h[key] is being accessed (changed). That means (only):
h[key] is set or changed. You can check this with this only one method: .

31

I provided a simple example hash implementation earlier today that
replicates the problem being discussed as I understand it. Opti, it seems
that you're the only one who can see your solution clearly. Could you
demonstrate it in code by patching that example and demonstrating its use?

That's fine if not. Butting heads here isn't going to accomplish anything
though. If you would like what you're suggesting to come to fruition, you
probably need to do the work yourself and get it accepted by the Ruby
maintainers. They are the only ones you must convince.

-Jeremy

···

On Thu, Jun 9, 2022 at 6:10 PM Die Optimisten <inform@die-optimisten.net> wrote:

Am 09.06.22 um 22:06 schrieb Austin Ziegler:


a = []
h = Hash.new(a)
a << 1 # should warn, right? If not, then what’s the point?
b = h[1]
b << 1 # should warn, right? If not, then what’s the point?
c = a
c << 1 # should warn, right? If not, then what’s the point?
h[1] << 1 # should warn, right?

VERY WRONG! Who is telling this? Yes, it's YOUR example and it's stupid!

I said: "warn if h[key] is being accessed (changed). That means (only):
h[key] is set or changed. You can check this with this only one method: .

32 
Hash.new do |hash, key|
  warn "accessing non-extant hash key #{key.inspect}"
  hash[key] = []
end

Array doesn't have an equivalent option, because it doesn't make sense
for an Array to support "read off the end" semantics. Array is not
Hash, and there is no reason for them to have matching APIs.

···

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

33

Hello!
Similarity was meant in relation to Array.new(count) {...} # where count
could be optional for more compatibility with Hash.
Unpleasant that Array.new {...} doesn't throw any error. (And does NOT
set the default as s,o. (me) would expect.
Opti

···

Am 10.06.22 um 14:34 schrieb Matthew Kerwin:

Hash.new do |hash, key|
   warn "accessing non-extant hash key #{key.inspect}"
   hash[key] = []
end

Array doesn't have an equivalent option, because it doesn't make sense
for an Array to support "read off the end" semantics. Array is not
Hash, and there is no reason for them to have matching APIs.