This had me scratching my head for a bit. I’ve seen this problem before in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It seemed weird
because it’s a constant and it shouldn’t change (https://git.io/vrqQO). Can
anyone figure out why?
[1] pry(#<listing repositories>)> HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
> From: "David Davis" <daviddavis@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Thursday, May 12, 2016 12:44:13 PM
> Subject: [foreman-dev] Ruby gotcha with constants and hashes
>
> This had me scratching my head for a bit. I’ve seen this problem before in
> the Foreman ecosystem so I figured I’d send an email about it.
>
> I was working on a test and got the following output below. It seemed weird
> because it’s a constant and it shouldn’t change (https://git.io/vrqQO). Can
> anyone figure out why?
It didn't "change" depending on how you look at it, object_id of the hash stayed
the same.
···
----- Original Message -----
[1] pry(#)> HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed it was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the MutableConstant
cop <http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant>.
I am thinking it might be a good idea to enable it for other repos. At the
very least, it should speed our code up.
Thoughts?
David
···
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It seemed
weird
because it’s a constant and it shouldn’t change (https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of the hash
stayed
the same.
[1] pry(#)> HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> From: "David Davis" <daviddavis@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Thursday, May 12, 2016 2:12:56 PM
> Subject: Re: [foreman-dev] Ruby gotcha with constants and hashes
>
> Yes, the value of the hash changed but it retained the same
> address/object_id (which I think was the problem: the code assumed it was
> getting back a value instead of an object reference).
>
> This was actually caught in hammer-cli-katello by running the MutableConstant
> cop <http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant>.
> I am thinking it might be a good idea to enable it for other repos. At the
> very least, it should speed our code up.
>
> Thoughts?
+1
Sounds good to me, if it needs to be modified it shouldn't be a constant.
···
----- Original Message -----
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin stephen@redhat.com > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It seemed
weird
because it’s a constant and it shouldn’t change (https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of the hash
stayed
the same.
[1] pry(#)> HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hello
I have mixed feelings about this. I understand the confusion but I don't think
it's too problematic. Constants in Ruby are not really constants anyway. You
can redefine them (getting just warning) unless you're in instance method. I
don't think majority of libraries would follow this cop suggestions so to
remain consistent I'd keep this as is.
I don't have strong opinion on this so If I'm the only one against, feel free
to enable it.
OT: note that classes are also just constants pointing to a singleton objects
(constant starts with capital letter) and you can change (undefine) them,
actually Rails uses this for auto-reloading. With hashes, arrays and other
complex objects I find this as a feature rather than bug, what's more
concerning to me is this
CONST = 'const'
CONST << ' modified'
CONST # => 'const modified'
···
--
Marek
On Thursday 12 of May 2016 14:12:56 David Davis wrote:
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed it was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the
MutableConstant cop
http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant. I
am thinking it might be a good idea to enable it for other repos. At the
very least, it should speed our code up.
Thoughts?
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin stephen@redhat.com > > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It seemed
weird
because it’s a constant and it shouldn’t change (https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of the hash
stayed
the same.
[1] pry(#)>
HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The fact that we’ve already uncovered one problem seems to me like it is a
problem. Also, I’m interested to know why you think modifying string
constants is concerning but not hash or array constants.
David
···
On Fri, May 13, 2016 at 3:54 AM, Marek Hulán wrote:
Hello
I have mixed feelings about this. I understand the confusion but I don’t
think
it’s too problematic. Constants in Ruby are not really constants anyway.
You
can redefine them (getting just warning) unless you’re in instance method.
I
don’t think majority of libraries would follow this cop suggestions so to
remain consistent I’d keep this as is.
I don’t have strong opinion on this so If I’m the only one against, feel
free
to enable it.
OT: note that classes are also just constants pointing to a singleton
objects
(constant starts with capital letter) and you can change (undefine) them,
actually Rails uses this for auto-reloading. With hashes, arrays and other
complex objects I find this as a feature rather than bug, what’s more
concerning to me is this
CONST = 'const’
CONST << ’ modified’
CONST # => ‘const modified’
–
Marek
On Thursday 12 of May 2016 14:12:56 David Davis wrote:
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed it was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the
MutableConstant cop
http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant.
I
am thinking it might be a good idea to enable it for other repos. At the
very least, it should speed our code up.
Thoughts?
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin stephen@redhat.com > > > > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem
before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It seemed
weird
because it’s a constant and it shouldn’t change (
https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of the
hash
stayed
the same.
[1] pry(#)>
HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Wait a second, isn't the constant dup'd?
If so, then the constant should technically be changing, right?
e.g.
2.2.4 :014 > H1 =
{ foo: 'bar', baz: 'qux' }
.freeze
2.2.4 :015 > H1.object_id
=> 122468880
2.2.4 :016 > H2 = H1.dup
2.2.4 :017 > H2.object_id
=> 41286800
2.2.4 :018 > H2[:baz] = "quux"
2.2.4 :019 > H1
=> {:foo=>"bar", :baz=>"qux"}
2.2.4 :020 > H2
=> {:foo=>"bar", :baz=>"quux"}
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
···
On Fri, May 13, 2016 at 8:55 AM, David Davis wrote:
The fact that we’ve already uncovered one problem seems to me like it is a
problem. Also, I’m interested to know why you think modifying string
constants is concerning but not hash or array constants.
David
On Fri, May 13, 2016 at 3:54 AM, Marek Hulán mhulan@redhat.com wrote:
Hello
I have mixed feelings about this. I understand the confusion but I don’t
think
it’s too problematic. Constants in Ruby are not really constants anyway.
You
can redefine them (getting just warning) unless you’re in instance
method. I
don’t think majority of libraries would follow this cop suggestions so to
remain consistent I’d keep this as is.
I don’t have strong opinion on this so If I’m the only one against, feel
free
to enable it.
OT: note that classes are also just constants pointing to a singleton
objects
(constant starts with capital letter) and you can change (undefine) them,
actually Rails uses this for auto-reloading. With hashes, arrays and other
complex objects I find this as a feature rather than bug, what’s more
concerning to me is this
CONST = 'const’
CONST << ’ modified’
CONST # => ‘const modified’
–
Marek
On Thursday 12 of May 2016 14:12:56 David Davis wrote:
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed it
was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the
MutableConstant cop
http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant.
I
am thinking it might be a good idea to enable it for other repos. At the
very least, it should speed our code up.
Thoughts?
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin stephen@redhat.com >> > >> > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem
before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It
seemed
weird
because it’s a constant and it shouldn’t change (
https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of the
hash
stayed
the same.
[1] pry(#)>
HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Should not be changing*
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
···
On Fri, May 13, 2016 at 9:20 AM, Andrew Kofink wrote:
Wait a second, isn’t the constant dup’d?
If so, then the constant should technically be changing, right?
e.g.
2.2.4 :014 > H1 =
{ foo: ‘bar’, baz: ‘qux’ }
.freeze
2.2.4 :015 > H1.object_id
=> 122468880
2.2.4 :016 > H2 = H1.dup
2.2.4 :017 > H2.object_id
=> 41286800
2.2.4 :018 > H2[:baz] = "quux"
2.2.4 :019 > H1
=> {:foo=>“bar”, :baz=>“qux”}
2.2.4 :020 > H2
=> {:foo=>“bar”, :baz=>“quux”}
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
On Fri, May 13, 2016 at 8:55 AM, David Davis daviddavis@redhat.com > wrote:
The fact that we’ve already uncovered one problem seems to me like it is
a problem. Also, I’m interested to know why you think modifying string
constants is concerning but not hash or array constants.
David
On Fri, May 13, 2016 at 3:54 AM, Marek Hulán mhulan@redhat.com wrote:
Hello
I have mixed feelings about this. I understand the confusion but I don’t
think
it’s too problematic. Constants in Ruby are not really constants anyway.
You
can redefine them (getting just warning) unless you’re in instance
method. I
don’t think majority of libraries would follow this cop suggestions so to
remain consistent I’d keep this as is.
I don’t have strong opinion on this so If I’m the only one against, feel
free
to enable it.
OT: note that classes are also just constants pointing to a singleton
objects
(constant starts with capital letter) and you can change (undefine) them,
actually Rails uses this for auto-reloading. With hashes, arrays and
other
complex objects I find this as a feature rather than bug, what’s more
concerning to me is this
CONST = 'const’
CONST << ’ modified’
CONST # => ‘const modified’
–
Marek
On Thursday 12 of May 2016 14:12:56 David Davis wrote:
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed it
was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the
MutableConstant cop
<
http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant>.
I
am thinking it might be a good idea to enable it for other repos. At
the
very least, it should speed our code up.
Thoughts?
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin stephen@redhat.com >>> > >>> > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem
before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It
seemed
weird
because it’s a constant and it shouldn’t change (
https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of
the hash
stayed
the same.
[1] pry(#)>
HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Yes, that’s correct. Although it might not be clear to developers that you
need to call dup if you assign your constant to a variable or return it
from a method:
[1] pry(main)> MY_HASH = {:a => 1}
{
:a => 1
}
[2] pry(main)> some_var = MY_HASH
{
:a => 1
}
[3] pry(main)> some_var.object_id
70355561000620
[4] pry(main)> MY_HASH.object_id
70355561000620
[5] pry(main)> some_var[:b] = 2
2
[6] pry(main)> some_var
{
:a => 1,
:b => 2
}
[7] pry(main)> MY_HASH
{
:a => 1,
:b => 2
}
My fix was in fact to call dup:
https://github.com/Katello/hammer-cli-katello/pull/397
David
···
On Fri, May 13, 2016 at 9:21 AM, Andrew Kofink wrote:
Should not be changing*
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
On Fri, May 13, 2016 at 9:20 AM, Andrew Kofink akofink@redhat.com wrote:
Wait a second, isn’t the constant dup’d?
If so, then the constant should technically be changing, right?
e.g.
2.2.4 :014 > H1 =
{ foo: ‘bar’, baz: ‘qux’ }
.freeze
2.2.4 :015 > H1.object_id
=> 122468880
2.2.4 :016 > H2 = H1.dup
2.2.4 :017 > H2.object_id
=> 41286800
2.2.4 :018 > H2[:baz] = “quux”
2.2.4 :019 > H1
=> {:foo=>“bar”, :baz=>“qux”}
2.2.4 :020 > H2
=> {:foo=>“bar”, :baz=>“quux”}
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
On Fri, May 13, 2016 at 8:55 AM, David Davis daviddavis@redhat.com >> wrote:
The fact that we’ve already uncovered one problem seems to me like it is
a problem. Also, I’m interested to know why you think modifying string
constants is concerning but not hash or array constants.
David
On Fri, May 13, 2016 at 3:54 AM, Marek Hulán mhulan@redhat.com wrote:
Hello
I have mixed feelings about this. I understand the confusion but I
don’t think
it’s too problematic. Constants in Ruby are not really constants
anyway. You
can redefine them (getting just warning) unless you’re in instance
method. I
don’t think majority of libraries would follow this cop suggestions so
to
remain consistent I’d keep this as is.
I don’t have strong opinion on this so If I’m the only one against,
feel free
to enable it.
OT: note that classes are also just constants pointing to a singleton
objects
(constant starts with capital letter) and you can change (undefine)
them,
actually Rails uses this for auto-reloading. With hashes, arrays and
other
complex objects I find this as a feature rather than bug, what’s more
concerning to me is this
CONST = ‘const’
CONST << ’ modified’
CONST # => ‘const modified’
–
Marek
On Thursday 12 of May 2016 14:12:56 David Davis wrote:
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed it
was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the
MutableConstant cop
<
http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant>.
I
am thinking it might be a good idea to enable it for other repos. At
the
very least, it should speed our code up.
Thoughts?
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin <stephen@redhat.com >>>> > >>>> > >>>> > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem
before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It
seemed
weird
because it’s a constant and it shouldn’t change (
https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of
the hash
stayed
the same.
[1] pry(#)>
HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> From: "Andrew Kofink" <akofink@redhat.com>
> To: foreman-dev@googlegroups.com
> Cc: "Marek Hulán" <mhulan@redhat.com>
> Sent: Friday, May 13, 2016 9:21:45 AM
> Subject: Re: [foreman-dev] Ruby gotcha with constants and hashes
>
> Should not be changing*
>
> Andrew Kofink
>
> Software Engineering Intern
> Red Hat Satellite 6
> akofink@redhat.com
>
>
> > Wait a second, isn't the constant dup'd?
That was part of the change that was just merged to fix the tests. In the previous
case, the hash wasn't frozen and passed by reference allowing anybody to change
the (in)constant's value (which is done here[1]).
[1] https://github.com/Katello/hammer-cli-katello/blob/master/lib/hammer_cli_katello/katello_environment_name_resolvable.rb#L10
···
----- Original Message -----
> On Fri, May 13, 2016 at 9:20 AM, Andrew Kofink wrote:
If so, then the constant should technically be changing, right?
e.g.
2.2.4 :014 > H1 =
{ foo: ‘bar’, baz: ‘qux’ }
.freeze
2.2.4 :015 > H1.object_id
=> 122468880
2.2.4 :016 > H2 = H1.dup
2.2.4 :017 > H2.object_id
=> 41286800
2.2.4 :018 > H2[:baz] = "quux"
2.2.4 :019 > H1
=> {:foo=>“bar”, :baz=>“qux”}
2.2.4 :020 > H2
=> {:foo=>“bar”, :baz=>“quux”}
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
On Fri, May 13, 2016 at 8:55 AM, David Davis daviddavis@redhat.com > > wrote:
The fact that we’ve already uncovered one problem seems to me like it is
a problem. Also, I’m interested to know why you think modifying string
constants is concerning but not hash or array constants.
David
On Fri, May 13, 2016 at 3:54 AM, Marek Hulán mhulan@redhat.com wrote:
Hello
I have mixed feelings about this. I understand the confusion but I don’t
think
it’s too problematic. Constants in Ruby are not really constants anyway.
You
can redefine them (getting just warning) unless you’re in instance
method. I
don’t think majority of libraries would follow this cop suggestions so to
remain consistent I’d keep this as is.
I don’t have strong opinion on this so If I’m the only one against, feel
free
to enable it.
OT: note that classes are also just constants pointing to a singleton
objects
(constant starts with capital letter) and you can change (undefine) them,
actually Rails uses this for auto-reloading. With hashes, arrays and
other
complex objects I find this as a feature rather than bug, what’s more
concerning to me is this
CONST = 'const’
CONST << ’ modified’
CONST # => ‘const modified’
–
Marek
On Thursday 12 of May 2016 14:12:56 David Davis wrote:
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed it
was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the
MutableConstant cop
<
http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant>.
I
am thinking it might be a good idea to enable it for other repos. At
the
very least, it should speed our code up.
Thoughts?
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin stephen@redhat.com > >>> > > >>> > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem
before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It
seemed
weird
because it’s a constant and it shouldn’t change (
https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of
the hash
stayed
the same.
[1] pry(#)>
HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ah, didn't realize that link already contained the fix. 
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
···
On Fri, May 13, 2016 at 9:36 AM, Stephen Benjamin wrote:
----- Original Message -----
From: “Andrew Kofink” akofink@redhat.com
To: foreman-dev@googlegroups.com
Cc: “Marek Hulán” mhulan@redhat.com
Sent: Friday, May 13, 2016 9:21:45 AM
Subject: Re: [foreman-dev] Ruby gotcha with constants and hashes
Should not be changing*
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
On Fri, May 13, 2016 at 9:20 AM, Andrew Kofink akofink@redhat.com > wrote:
Wait a second, isn’t the constant dup’d?
That was part of the change that was just merged to fix the tests. In the
previous
case, the hash wasn’t frozen and passed by reference allowing anybody to
change
the (in)constant’s value (which is done here[1]).
[1]
https://github.com/Katello/hammer-cli-katello/blob/master/lib/hammer_cli_katello/katello_environment_name_resolvable.rb#L10
If so, then the constant should technically be changing, right?
e.g.
2.2.4 :014 > H1 =
{ foo: ‘bar’, baz: ‘qux’ }
.freeze
2.2.4 :015 > H1.object_id
=> 122468880
2.2.4 :016 > H2 = H1.dup
2.2.4 :017 > H2.object_id
=> 41286800
2.2.4 :018 > H2[:baz] = "quux"
2.2.4 :019 > H1
=> {:foo=>“bar”, :baz=>“qux”}
2.2.4 :020 > H2
=> {:foo=>“bar”, :baz=>“quux”}
Andrew Kofink
Software Engineering Intern
Red Hat Satellite 6
akofink@redhat.com
On Fri, May 13, 2016 at 8:55 AM, David Davis daviddavis@redhat.com > > > wrote:
The fact that we’ve already uncovered one problem seems to me like it
is
a problem. Also, I’m interested to know why you think modifying string
constants is concerning but not hash or array constants.
David
On Fri, May 13, 2016 at 3:54 AM, Marek Hulán mhulan@redhat.com > wrote:
Hello
I have mixed feelings about this. I understand the confusion but I
don’t
think
it’s too problematic. Constants in Ruby are not really constants
anyway.
You
can redefine them (getting just warning) unless you’re in instance
method. I
don’t think majority of libraries would follow this cop suggestions
so to
remain consistent I’d keep this as is.
I don’t have strong opinion on this so If I’m the only one against,
feel
free
to enable it.
OT: note that classes are also just constants pointing to a singleton
objects
(constant starts with capital letter) and you can change (undefine)
them,
actually Rails uses this for auto-reloading. With hashes, arrays and
other
complex objects I find this as a feature rather than bug, what’s more
concerning to me is this
CONST = 'const’
CONST << ’ modified’
CONST # => ‘const modified’
–
Marek
On Thursday 12 of May 2016 14:12:56 David Davis wrote:
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed
it
was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the
MutableConstant cop
<
http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant>.
I
am thinking it might be a good idea to enable it for other repos.
At
the
very least, it should speed our code up.
Thoughts?
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin < > stephen@redhat.com> > > >>> > > > >>> > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this
problem
before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It
seemed
weird
because it’s a constant and it shouldn’t change (
https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of
the hash
stayed
the same.
[1] pry(#)>
HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the
Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from
it,
send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the
Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> The fact that we’ve already uncovered one problem seems to me like it is a
> problem.
That's fair, I just haven't encountered it myself yet.
> Also, I’m interested to know why you think modifying string
> constants is concerning but not hash or array constants.
I said more concerning 
somehow I look at strings as simple data type,
arrays, hashes, structs, sets etc are complex composes of multiple types. But
I understand that there are no primitives, just objects, in Ruby so as long as
object is mutable, it might change even if set as constant.
Anyway, seems no one else has objections and I don't have strong opinion, so
I'll get used to freezing
···
On Friday 13 of May 2016 08:55:35 David Davis wrote:
–
Marek
David
On Fri, May 13, 2016 at 3:54 AM, Marek Hulán mhulan@redhat.com wrote:
Hello
I have mixed feelings about this. I understand the confusion but I don’t
think
it’s too problematic. Constants in Ruby are not really constants anyway.
You
can redefine them (getting just warning) unless you’re in instance method.
I
don’t think majority of libraries would follow this cop suggestions so to
remain consistent I’d keep this as is.
I don’t have strong opinion on this so If I’m the only one against, feel
free
to enable it.
OT: note that classes are also just constants pointing to a singleton
objects
(constant starts with capital letter) and you can change (undefine) them,
actually Rails uses this for auto-reloading. With hashes, arrays and other
complex objects I find this as a feature rather than bug, what’s more
concerning to me is this
CONST = 'const’
CONST << ’ modified’
CONST # => ‘const modified’
–
Marek
On Thursday 12 of May 2016 14:12:56 David Davis wrote:
Yes, the value of the hash changed but it retained the same
address/object_id (which I think was the problem: the code assumed it
was
getting back a value instead of an object reference).
This was actually caught in hammer-cli-katello by running the
MutableConstant cop
http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/MutableConstant
.
I
am thinking it might be a good idea to enable it for other repos. At the
very least, it should speed our code up.
Thoughts?
David
On Thu, May 12, 2016 at 1:55 PM, Stephen Benjamin stephen@redhat.com > > > > > > wrote:
----- Original Message -----
From: “David Davis” daviddavis@redhat.com
To: foreman-dev@googlegroups.com
Sent: Thursday, May 12, 2016 12:44:13 PM
Subject: [foreman-dev] Ruby gotcha with constants and hashes
This had me scratching my head for a bit. I’ve seen this problem
before
in
the Foreman ecosystem so I figured I’d send an email about it.
I was working on a test and got the following output below. It
seemed
weird
because it’s a constant and it shouldn’t change (
https://git.io/vrqQO).
Can
anyone figure out why?
It didn’t “change” depending on how you look at it, object_id of the
hash
stayed
the same.
[1] pry(#)>
HammerCLIKatello::RESOURCE_NAME_MAPPING
{
:system => :content_host,
:
:environment => :lifecycle_environment
}
Here’s a hint: https://git.io/vrq77
David
–
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to the Google
Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
