Hash productivity

ruby-talk
1

Hi,

Once again I state. The amount of time lost hunting bugs which lie on the
ambiguity of hash keys type between symbol and string is horrendous. Here I
am and finally there it goes: it should be a symbol not a string. Is it
just me? Can we please do something to fix this problem?

Thanks,

Daniel

2

One thing you might try to detect this problem is to use Hash.fetch to get values out of a Hash — rather than “silently” returning nil it’ll raise an exception or you can specify other behaviour.

Another approach might be to sanitise the hash at the boundary of your code, if that makes sense for your use case.

ActiveSupport has the with_indifferent_access thing which “deals” with the “ambiguity”, but in my opinion that just extends the scope of the area of code in which the reader isn’t sure if keys are symbols or strings.

Hope this helps,

Mike

···

On Jan 16, 2017, at 6:02 AM, Daniel Ferreira <subtileos@gmail.com> wrote:

Hi,

Once again I state. The amount of time lost hunting bugs which lie on the ambiguity of hash keys type between symbol and string is horrendous. Here I am and finally there it goes: it should be a symbol not a string. Is it just me? Can we please do something to fix this problem?

Thanks,

Daniel

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

--

Mike Stok <mike@stok.ca>
http://www.stok.ca/~mike/

The "`Stok' disclaimers" apply.

3

Once again I state. The amount of time lost hunting bugs which lie on the ambiguity of hash keys type between symbol and string is horrendous. Here I am and finally there it goes: it should be a symbol not a string. Is it just me? Can we please do something to fix this problem?

Well of course changing the functionality of Hash would break an awful lot of existing code, so that's probably not going to ever be the default behaviour.

But. I feel your pain. This very thing causes me no end of problems, too. In fact I got so fed up with it I cooked up a little mad science gem to use instead of a hash in passing between classes: GitHub - andy-twosticks/octothorpe: A simple supplement/replacement for the Ruby Hash class.

I have no idea if this is of any use to you, but, you never know...

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

4

I do put in place those best practices, but it doesn't avoid edge cases.
There situations where it's very hard to decide what should be the
interface.

But I do tend to favor strings over symbols internally. But again that can
not be a fundamentalistic rule.

Thanks,

Daniel

···

On Mon, 16 Jan 2017 at 11:52, Mike Stok <mike@stok.ca> wrote:

On Jan 16, 2017, at 6:02 AM, Daniel Ferreira <subtileos@gmail.com> wrote:

Hi,

Once again I state. The amount of time lost hunting bugs which lie on the
ambiguity of hash keys type between symbol and string is horrendous. Here I
am and finally there it goes: it should be a symbol not a string. Is it
just me? Can we please do something to fix this problem?

Thanks,

Daniel

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&gt;

One thing you might try to detect this problem is to use Hash.fetch to get
values out of a Hash — rather than “silently” returning nil it’ll raise an
exception or you can specify other behaviour.

Another approach might be to sanitise the hash at the boundary of your
code, if that makes sense for your use case.

ActiveSupport has the with_indifferent_access thing which “deals” with the
“ambiguity”, but in my opinion that just extends the scope of the area of
code in which the reader isn’t sure if keys are symbols or strings.

Hope this helps,

Mike

--

Mike Stok <mike@stok.ca>
Mike Stok

The "`Stok' disclaimers" apply.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Hi Mike,

5

There is no ambiguity. If you define your hashes with string keys
it has string keys, if you use symbol keys it has symbol keys,
same for integer keys, and so on.

How would you want to "fix" it: disallow strings to be hash keys
while any other object still can be used as key?

Or am I missing some context? (Like specific gems you are
thinking about.)

Regards,
Marcus

···

Am 16.01.2017 um 12:02 schrieb Daniel Ferreira:

Once again I state. The amount of time lost hunting bugs which lie on
the ambiguity of hash keys type between symbol and string is horrendous.
Here I am and finally there it goes: it should be a symbol not a string.
Is it just me? Can we please do something to fix this problem?

--
GitHub: stomar (Marcus Stollsteimer) · GitHub
PGP: 0x6B3A101A

6

Thanks Andy, but I don't feel stepping away from using hashes is the right
step in the right direction.

We have refinements and HashWithIndifferentAccess but for me it should be
real thing: Hash.

So many discussions around this isn't it?
The solution should be there somewhere but I feel it wasn't found yet. If
only people were worried about this serious problem in the ruby language.

Symbols introduced a number of problems in order to fix one (or maybe more
than one?)

My view anyway.

Thanks,

Daniel

···

On Mon, 16 Jan 2017 at 11:19, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:

>>>>

Once again I state. The amount of time lost hunting bugs which lie on the
ambiguity of hash keys type between symbol and string is horrendous. Here I
am and finally there it goes: it should be a symbol not a string. Is it
just me? Can we please do something to fix this problem?

<<<<

Well of course changing the functionality of Hash would break an awful lot
of existing code, so that's probably not going to ever be the default
behaviour.

But. I feel your pain. This very thing causes me no end of problems, too.
In fact I got so fed up with it I cooked up a little mad science gem to use
instead of a hash in passing between classes:
GitHub - andy-twosticks/octothorpe: A simple supplement/replacement for the Ruby Hash class.

I have no idea if this is of any use to you, but, you never know...

Click here to view Company Information and Confidentiality Notice.<
http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

7

Also one thing that is worth to reason about is the fact that all these
best practices and personal gems out there have costs at all levels and are
being tried out without much success because the bottom problem is in the
way.

I advocate throwing to the bin all the cosmetic and start to think
seriously about taking out the mountain from the way.

I want a straight highway not a hundreds curves tiny road full of traffic
if this image makes any sense to you.

Thanks,

Daniel

···

On Mon, 16 Jan 2017 at 11:57, Daniel Ferreira <subtileos@gmail.com> wrote:

On Mon, 16 Jan 2017 at 11:52, Mike Stok <mike@stok.ca> wrote:

On Jan 16, 2017, at 6:02 AM, Daniel Ferreira <subtileos@gmail.com> wrote:

Hi,

Once again I state. The amount of time lost hunting bugs which lie on the
ambiguity of hash keys type between symbol and string is horrendous. Here I
am and finally there it goes: it should be a symbol not a string. Is it
just me? Can we please do something to fix this problem?

Thanks,

Daniel

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&gt;

One thing you might try to detect this problem is to use Hash.fetch to get
values out of a Hash — rather than “silently” returning nil it’ll raise an
exception or you can specify other behaviour.

Another approach might be to sanitise the hash at the boundary of your
code, if that makes sense for your use case.

ActiveSupport has the with_indifferent_access thing which “deals” with the
“ambiguity”, but in my opinion that just extends the scope of the area of
code in which the reader isn’t sure if keys are symbols or strings.

Hope this helps,

Mike

--

Mike Stok <mike@stok.ca>
Mike Stok

The "`Stok' disclaimers" apply.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Hi Mike,

I do put in place those best practices, but it doesn't avoid edge cases.
There situations where it's very hard to decide what should be the
interface.

But I do tend to favor strings over symbols internally. But again that can
not be a fundamentalistic rule.

Thanks,

Daniel

8

Thanks Andy, but I don't feel stepping away from using hashes is the right step in the right direction.
We have refinements and HashWithIndifferentAccess but for me it should be real thing: Hash.

I mean this philosophically rather than pedantically, but: since the Hash class is what it is, maybe you **don't** need the real thing. Maybe you need something else. Something more like what you wish Hash was.

As you say, there are a myriad of different third-party classes out there that you could use instead. All of them start from the premise that the basic hash, unless it is very simple, is not suitable for passing data around between objects.

I have no idea how complex your hashes are, but if there are only one or two and they are quite complex then maybe you should also think about a Struct, or even some sort of message class...

Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

9

One thing that is missing from your "requirement" is that, even if you
manage to include in the stdlib a class that behaves as you say, a
more basic Hash class would be needed. The hash data structure in
which any object can be the key is still a fundamentally useful
structure for all languages, so you cannot remove that. So, the only
conclusion is that you want two different things, because you cannot
remove from the language a data structure in which a Symbol as a key
is different than a String as a key. So, you would need something
different, something like HashWithIndifferentAccess, or something even
more suited to your use case. At that point, however, we are not
discussing about a generically useful data structure for the stdlib,
but about something tuned for specific use cases. Whether those use
cases are ubiquitous enough to warrant a class in the stdlib to solve
them, that would be a different story, but a Hash with generic objects
as keys should not be removed from the stdlib.

My 2 cents.

Jesus.

···

On Mon, Jan 16, 2017 at 1:09 PM, Daniel Ferreira <subtileos@gmail.com> wrote:

On Mon, 16 Jan 2017 at 11:57, Daniel Ferreira <subtileos@gmail.com> wrote:

On Mon, 16 Jan 2017 at 11:52, Mike Stok <mike@stok.ca> wrote:

On Jan 16, 2017, at 6:02 AM, Daniel Ferreira <subtileos@gmail.com> wrote:

Hi,

Once again I state. The amount of time lost hunting bugs which lie on the
ambiguity of hash keys type between symbol and string is horrendous. Here I
am and finally there it goes: it should be a symbol not a string. Is it just
me? Can we please do something to fix this problem?

10

the hash table works. The problem exists because all over the place symbols
and strings are being used as hash keys interchangeably. Even if I try to
put a rule on my code I can not neglect the mix between this to type of
objects.
The drastic thing for me would be to remove symbols altogether from ruby
core and force immutable strings everywhere.

That would be the perfect world to me.

Thanks,

Daniel

···

On Mon, 16 Jan 2017 at 13:51, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:

>>>>>>>>

Thanks Andy, but I don't feel stepping away from using hashes is the right
step in the right direction.

We have refinements and HashWithIndifferentAccess but for me it should be
real thing: Hash.

<<<<<<<<

I mean this philosophically rather than pedantically, but: since the Hash
class is what it is, maybe you **don't** need the real thing. Maybe you
need something else. Something more like what you wish Hash was.

As you say, there are a myriad of different third-party classes out there
that you could use instead. All of them start from the premise that the
basic hash, unless it is very simple, is not suitable for passing data
around between objects.

I have no idea how complex your hashes are, but if there are only one or
two and they are quite complex then maybe you should also think about a
Struct, or even some sort of message class...

Click here to view Company Information and Confidentiality Notice.<
http://www.jameshall.co.uk/index.php/small-print/email-disclaimer&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

The way I see the problem is that it is not a question of changing the way

11

Sorry for quoting myself, but wanted to clarify: when I talk about the
stdlib I mean core + stdlib.

Jesus.

···

On Mon, Jan 16, 2017 at 2:22 PM, Jesús Gabriel y Galán <jgabrielygalan@gmail.com> wrote:

On Mon, Jan 16, 2017 at 1:09 PM, Daniel Ferreira <subtileos@gmail.com> wrote:

On Mon, 16 Jan 2017 at 11:57, Daniel Ferreira <subtileos@gmail.com> wrote:

On Mon, 16 Jan 2017 at 11:52, Mike Stok <mike@stok.ca> wrote:

On Jan 16, 2017, at 6:02 AM, Daniel Ferreira <subtileos@gmail.com> wrote:

Hi,

Once again I state. The amount of time lost hunting bugs which lie on the
ambiguity of hash keys type between symbol and string is horrendous. Here I
am and finally there it goes: it should be a symbol not a string. Is it just
me? Can we please do something to fix this problem?

One thing that is missing from your "requirement" is that, even if you
manage to include in the stdlib a class that behaves as you say, a
more basic Hash class would be needed. The hash data structure in
which any object can be the key is still a fundamentally useful
structure for all languages, so you cannot remove that. So, the only
conclusion is that you want two different things, because you cannot
remove from the language a data structure in which a Symbol as a key
is different than a String as a key. So, you would need something
different, something like HashWithIndifferentAccess, or something even
more suited to your use case. At that point, however, we are not
discussing about a generically useful data structure for the stdlib,
but about something tuned for specific use cases. Whether those use
cases are ubiquitous enough to warrant a class in the stdlib to solve
them, that would be a different story, but a Hash with generic objects
as keys should not be removed from the stdlib.

My 2 cents.

Jesus.

12

Quoting Daniel Ferreira (subtileos@gmail.com):

   The drastic thing for me would be to remove symbols altogether from ruby
   core and force immutable strings everywhere.
   That would be the perfect world to me.

I was afraid you'd say so. Symbols are key factors in Ruby for
performance and memory economics (you save / move around the symbol
instead of the whole string), and OTOH mutable strings represent much
of Ruby's flexibilty (I also move around binary data as ruby strings),
so I for one fervidly hope that your proposal will not snowball...

Carlo

···

Subject: Re: Hash productivity
  Date: lun 16 gen 17 01:59:32 +0000

--
  * Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

13

It doesn't have to be like I stated but I'm glad we have here a very high
profile discussion.
It means people do care about the problem and feel the pain as much as I do.
This makes me happy.
We all love ruby.
Having a mountain in our way is not good to anyone.
So lets discuss this and come up with one solution.
One solution that for me should have the goal of putting ruby community in
the right track.
Every ruby developer should start to use hashes in the same way so that we
may all start to speak the same language again.
There is a mountain. Lets join the engineers and find out the best way to
design and build the best path for people to cross without buts of any sort.
I believe that if we try real hard we will be able to achieve it.

Thanks,
Daniel

···

On Mon, 16 Jan 2017 at 14:14, Carlo E. Prelz <fluido@fluido.as> wrote:

        Subject: Re: Hash productivity

        Date: lun 16 gen 17 01:59:32 +0000

Quoting Daniel Ferreira (subtileos@gmail.com):

> The drastic thing for me would be to remove symbols altogether from
ruby

> core and force immutable strings everywhere.

> That would be the perfect world to me.

I was afraid you'd say so. Symbols are key factors in Ruby for

performance and memory economics (you save / move around the symbol

instead of the whole string), and OTOH mutable strings represent much

of Ruby's flexibilty (I also move around binary data as ruby strings),

so I for one fervidly hope that your proposal will not snowball...

Carlo

--

  * Se la Strada e la sua Virtu' non fossero state messe da parte,

* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe

  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Thanks Carlo.

14

Quoting Daniel Ferreira (subtileos@gmail.com):

   Having a mountain in our way is not good to anyone.

You know, the dividing point here is that for me (and I may not be
alone) the real mountain would appear out of the blue if the semantics
of Hash were to change... I have also been (albeit rarely) bit by bugs
due to confusing between symbols and strings - and the difference has
indeed been one of the most hard-to-swallow concepts for me when I
began, long time ago. But now that *that* mountain is behind my back,
the current semantics work well for me, and sacrificing performance or
flexibility would be highly undesirable.

Carlo

···

Subject: Re: Hash productivity
  Date: lun 16 gen 17 02:27:25 +0000

--
  * Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

15

I'm impressed with that statement. I got an image of a samurai monk holding
all that wait with the strength of his mine.
I also want to achieve that nirvana.
Dead serious here.
If you have the secret I'm all hears.
Maybe the solution I'm striving for already exists?

Thanks,
Daniel

···

On Mon, 16 Jan 2017 at 14:36, Carlo E. Prelz <fluido@fluido.as> wrote:

        Subject: Re: Hash productivity

        Date: lun 16 gen 17 02:27:25 +0000

Quoting Daniel Ferreira (subtileos@gmail.com):

> Having a mountain in our way is not good to anyone.

You know, the dividing point here is that for me (and I may not be

alone) the real mountain would appear out of the blue if the semantics

of Hash were to change... I have also been (albeit rarely) bit by bugs

due to confusing between symbols and strings - and the difference has

indeed been one of the most hard-to-swallow concepts for me when I

began, long time ago. But now that *that* mountain is behind my back,

the current semantics work well for me, and sacrificing performance or

flexibility would be highly undesirable.

Carlo

--

  * Se la Strada e la sua Virtu' non fossero state messe da parte,

* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe

  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Can you share with your secret to keep it behind your back?

16

Quoting Daniel Ferreira (subtileos@gmail.com):

   Can you share with your secret to keep it behind your back?
   I'm impressed with that statement. I got an image of a samurai
   monk

:wink:

Just writing code, and writing code, and writing code, (and debugging
code)...

Are you familiar with this booklet? When I first read it, it mapped
more directly to my experience, but it is still very wise and very
appropriate...

Anyway, at some point, you will have a cluster of synapses defining
string, and another one defining symbol, and you won't confuse among
them anymore. You will use strings when it is best to use strings and
symbols when it is best to use symbols.

And you will still have bugs in your code...

Carlo

···

Subject: Re: Hash productivity
  Date: lun 16 gen 17 02:41:30 +0000

--
  * Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

17

read and spread the knowledge.
I'm talking about ruby hash rules.
Can we come up with something like that as a starting point?

Thanks,

Daniel

···

On Mon, 16 Jan 2017 at 14:50, Carlo E. Prelz <fluido@fluido.as> wrote:

        Subject: Re: Hash productivity

        Date: lun 16 gen 17 02:41:30 +0000

Quoting Daniel Ferreira (subtileos@gmail.com):

> Can you share with your secret to keep it behind your back?

> I'm impressed with that statement. I got an image of a samurai

> monk

:wink:

Just writing code, and writing code, and writing code, (and debugging

code)...

Are you familiar with this booklet? When I first read it, it mapped

more directly to my experience, but it is still very wise and very

appropriate...

http://paranormal.se/article/tao-of-programming.pdf

Anyway, at some point, you will have a cluster of synapses defining

string, and another one defining symbol, and you won't confuse among

them anymore. You will use strings when it is best to use strings and

symbols when it is best to use symbols.

And you will still have bugs in your code...

Carlo

--

  * Se la Strada e la sua Virtu' non fossero state messe da parte,

* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe

  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Wouldn't it be better to have those rules written some where people could

18

For instance, If we do have to leave with booth strings and symbols, shall
we favor always symbols over strings or the opposite? Why?

···

On Mon, 16 Jan 2017 at 14:54, Daniel Ferreira <subtileos@gmail.com> wrote:

On Mon, 16 Jan 2017 at 14:50, Carlo E. Prelz <fluido@fluido.as> wrote:

        Subject: Re: Hash productivity

        Date: lun 16 gen 17 02:41:30 +0000

Quoting Daniel Ferreira (subtileos@gmail.com):

> Can you share with your secret to keep it behind your back?

> I'm impressed with that statement. I got an image of a samurai

> monk

:wink:

Just writing code, and writing code, and writing code, (and debugging

code)...

Are you familiar with this booklet? When I first read it, it mapped

more directly to my experience, but it is still very wise and very

appropriate...

http://paranormal.se/article/tao-of-programming.pdf

Anyway, at some point, you will have a cluster of synapses defining

string, and another one defining symbol, and you won't confuse among

them anymore. You will use strings when it is best to use strings and

symbols when it is best to use symbols.

And you will still have bugs in your code...

Carlo

--

  * Se la Strada e la sua Virtu' non fossero state messe da parte,

* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe

  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>

<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Wouldn't it be better to have those rules written some where people could
read and spread the knowledge.
I'm talking about ruby hash rules.
Can we come up with something like that as a starting point?

Thanks,

Daniel

19

Quoting Daniel Ferreira (subtileos@gmail.com):

   For instance, If we do have to leave with booth strings and symbols, shall
   we favor always symbols over strings or the opposite? Why?

Neither, of course. Sometimes strings, sometimes symbols.

Rigid rules are fragile, they usually do not lead to better code.

Carlo

···

Subject: Re: Hash productivity
  Date: lun 16 gen 17 03:04:53 +0000

--
  * Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
  * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

20

[... massive amount of quotes omitted ...]

Daniel,

your threads/posts are extremely hard to read (for me at least),
because of the heavy amount of quoting. Could you please trim
the quoted text... that would make it so much easier to follow
the discussion.

Thanks,
Marcus

···

Am 16.01.2017 um 16:04 schrieb Daniel Ferreira: