encapsulation issue

[James French]

Hi,

Is there any way of providing read only access to an array? (problem shown =
by code below).

class A

def initialize
@dependencies =3D []
end

# intended to be read only access
def dependencies
@dependencies
end

def addDependency(d)
@dependencies << d
puts "adding #{d}"
end
end


a =3D A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

puts a.dependencies # foo and bar both in array


Any suggestions appreciated,
James

 

[David A. Black]

Hi --

Hi,

Is there any way of providing read only access to an array? (problem shown by code below).

class A

def initialize
@dependencies = []
end

# intended to be read only access
def dependencies
@dependencies
end

def addDependency(d)
@dependencies << d
puts "adding #{d}"
end
end


a = A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

puts a.dependencies # foo and bar both in array

You can freeze the array:

a = [].freeze
a << 1 # TypeError: can't modify frozen array


David

--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Tom Stuart]

Hi --

Hi,

Is there any way of providing read only access to an array? (problem sho= wn
by code below).

class A

=A0def initialize
=A0 @dependencies =3D []
=A0end

=A0# intended to be read only access
=A0def dependencies
=A0 @dependencies
=A0end

=A0def addDependency(d)
=A0 @dependencies << d
=A0 puts "adding #{d}"
=A0end
end


a =3D A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

puts a.dependencies =A0 # foo and bar both in array

You can freeze the array:

=A0a =3D [].freeze
=A0a << 1 =A0 =A0 =A0 =A0 =A0# TypeError: can't modify frozen array

You could also dup it:

class A
def dependencies
@dependencies.dup
end
end

a =3D A.new
a.addDependency "foo"
a.dependencies << "bar"
puts a.dependencies # =3D> ["foo"]

 

[Aldric Giacomoni]

Hi,

Is there any way of providing read only access to an array?

I was going to suggest attr_reader :dependencies but a quick test showed
that there's more there than meets the eye.. Oddly.

 

[Ralph Shnelvar]

James,

It appears, also, that changing @dependencies to a constant also does
not help. Strange.

Ralph


Friday, November 6, 2009, 6:50:30 AM, you wrote:

JF> Hi,

JF> Is there any way of providing read only access to an array? (problem shown by code below).

JF> class A

JF> def initialize
JF> @dependencies = []
JF> end

JF> # intended to be read only access
JF> def dependencies
JF> @dependencies
JF> end

JF> def addDependency(d)
JF> @dependencies << d
JF> puts "adding #{d}"
JF> end
JF> end


JF> a = A.new
JF> a.addDependency("foo")
JF> a.dependencies << "bar" # encapsulation subverted

JF> puts a.dependencies # foo and bar both in array


JF> Any suggestions appreciated,
JF> James

 

[James French]

-----Original Message-----
From: David A. Black [mailto:[email protected]]
Sent: 06 November 2009 14:01
To: ruby-talk ML
Subject: Re: encapsulation issue
=20
Hi --
=20
On Fri, 6 Nov 2009, James French wrote:
=20

Hi,

Is there any way of providing read only access to an array? (problem shown by code below).

class A

def initialize
@dependencies =3D []
end

# intended to be read only access
def dependencies
@dependencies
end

def addDependency(d)
@dependencies << d
puts "adding #{d}"
end
end


a =3D A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

puts a.dependencies # foo and bar both in array

=20
You can freeze the array:
=20
a =3D [].freeze
a << 1 # TypeError: can't modify frozen array
=20
=20
David
=20
--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com
=20
David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

But then I can't legitimately push to it in addDependency...

 

[James French]

-----Original Message-----
From: Tom Stuart [mailto:[email protected]]
Sent: 06 November 2009 14:06
To: ruby-talk ML
Subject: Re: encapsulation issue
=20

Hi --

Hi,

Is there any way of providing read only access to an array? (problem shown
by code below).

class A

=A0def initialize
=A0 @dependencies =3D []
=A0end

=A0# intended to be read only access
=A0def dependencies
=A0 @dependencies
=A0end

=A0def addDependency(d)
=A0 @dependencies << d
=A0 puts "adding #{d}"
=A0end
end


a =3D A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

puts a.dependencies =A0 # foo and bar both in array

You can freeze the array:

=A0a =3D [].freeze
=A0a << 1 =A0 =A0 =A0 =A0 =A0# TypeError: can't modify frozen array

=20
You could also dup it:
=20
class A
def dependencies
@dependencies.dup
end
end
=20
a =3D A.new
a.addDependency "foo"
a.dependencies << "bar"
puts a.dependencies # =3D> ["foo"]

I don't think it solves it that nicely because as well as duplicating data =
which doesn't feel good, you've then got a line that looks as though it doe=
s something but doesn't. I guess it could raise an error somehow.

 

[Seebs]

But then I can't legitimately push to it in addDependency...

No, but you could dup-and-append when you hit that.

I think you pretty much have to dup the object in this case.

Hmm. Okay, imagine this. Define a new Array-like class, which has an
Array as an internal member, but overrides all the things which modify that
array, then return one wrapped around the object. At least you're then
limiting the amount of duplication you do.

A question naturally arises: What do you want to happen if I try to
send a modify-yourself message to a member of the array?

-s

 

[David A. Black]

Hi --

-----Original Message-----
From: David A. Black [mailto:[email protected]]
Sent: 06 November 2009 14:01
To: ruby-talk ML
Subject: Re: encapsulation issue

Hi --

Hi,

Is there any way of providing read only access to an array? (problem shown by code below).

class A

def initialize
@dependencies = []
end

# intended to be read only access
def dependencies
@dependencies
end

def addDependency(d)
@dependencies << d
puts "adding #{d}"
end
end


a = A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

puts a.dependencies # foo and bar both in array

You can freeze the array:

a = [].freeze
a << 1 # TypeError: can't modify frozen array


David

--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

But then I can't legitimately push to it in addDependency...

Whoops. I had a nagging feeling I wasn't giving the question enough
attention when I answered

I would probably favor the dup approach for the reader. In the end,
someone can get around it:

a.instance_eval { @dependencies << "bar" }

But it would at least keep away casual and accidental appenders.


David

--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Gavin Sinclair]

Is there any way of providing read only access to an array? [...]


a = A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

Ask yourself if it's really necessary to implement #dependencies.
(The answer may be 'yes'; I'm just saying don't assume it is.)

For instance, you could provide access to the dependencies like this

class A
# initialise and add_dependency as before

include Enumerable
def each(&block); @dependencies.each(&block); end

def [](n)
@dependencies[n] # possibly .dup this
end
end

a = A.new
a.add_dependency "foo"
a.each do ... end
a.map { ... }
a.grep(...)
a[5]

I've often found, when wrapping a basic data type, that I don't need
access to the 'guts' of that type; I only need to do a certain set of
things, so I implement them and leave it at that.

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

wrote:

Hi,

Is there any way of providing read only access to an array? (problem shown
by code below).

class A

def initialize
@dependencies = []
end

# intended to be read only access
def dependencies
@dependencies
end

def addDependency(d)
@dependencies << d
puts "adding #{d}"
end
end


a = A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

puts a.dependencies # foo and bar both in array


Any suggestions appreciated,
James

Ruby is a dynamic language, as David pointed out, you can always get around
whatever someone does. I think the point isn't so much to make it impossible
for them to do something, but rather to make it clear how it was anticipated
that it would be used. If they want to go so far as to override the methods,
or perform instance_eval to get at the variable, then I'd take that as a
very deliberate effort, so due to their determination to get around your
design, I would just assume that they had a legitimate reason to do so, or
at least if it blows up, they'll have no cause to be upset with you for it.

I don't know how you are trying to use the class, that you feel the need to
return an array that cannot be altered, but you could define methods which
give this functionality without ever exposing the array itself, something
like this:


# consider defining methods to give the functionality you might want
# without exposing the guts of your class to the world
class Configuration
def initialize() @dependencies = [] end
def add_dependency(d) @dependencies << d end

def each_dependency
@dependencies.each { |dep| yield dep }
end
end

config = Configuration.new
config.add_dependency :dependency1
config.add_dependency :dependency2
config.add_dependency :dependency3

config.each_dependency do |dependency|
puts "I am accessing #{dependency}, " \
"without ever seeing the array."
end



# Of course, they can always get around whatever you have done,
# in the above, there is no way to get at @dependencies from the
# outside world, but in their code they could just add the code below
class Configuration
attr_accessor :dependencies
end

p config.dependencies

__END__
Ruby is not about strict rigid code, or forcing people to use it
a certain way, it is dynamic. You have made your intentions clear,
at this point, if the user is not satisfied with your intentions,
then you must trust them to know what is best for their needs.
Something like this will not occur by accident, they have quite
deliberately decided that they need to break the encapsulation.

 

[James French]

-----Original Message-----
From: Gavin Sinclair [mailto:[email protected]]
Sent: 06 November 2009 23:56
To: ruby-talk ML
Subject: Re: encapsulation issue
=20

Is there any way of providing read only access to an array? [...]


a =3D A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

=20
Ask yourself if it's really necessary to implement #dependencies.
(The answer may be 'yes'; I'm just saying don't assume it is.)
=20
For instance, you could provide access to the dependencies like this
=20
class A
# initialise and add_dependency as before
=20
include Enumerable
def each(&block); @dependencies.each(&block); end
=20
def [](n)
@dependencies[n] # possibly .dup this
end
end
=20
a =3D A.new
a.add_dependency "foo"
a.each do ... end
a.map { ... }
a.grep(...)
a[5]
=20
I've often found, when wrapping a basic data type, that I don't need
access to the 'guts' of that type; I only need to do a certain set of
things, so I implement them and leave it at that.
=20

Thanks for that. I think I may go that way.

 

[James French]

-----Original Message-----
From: Josh Cheek [mailto:[email protected]]
Sent: 07 November 2009 02:43
To: ruby-talk ML
Subject: Re: encapsulation issue
=20
On Fri, Nov 6, 2009 at 7:50 AM, James French
<[email protected]

wrote: =20
Hi,

Is there any way of providing read only access to an array? (problem shown
by code below).

class A

def initialize
@dependencies =3D []
end

# intended to be read only access
def dependencies
@dependencies
end

def addDependency(d)
@dependencies << d
puts "adding #{d}"
end
end


a =3D A.new
a.addDependency("foo")
a.dependencies << "bar" # encapsulation subverted

puts a.dependencies # foo and bar both in array


Any suggestions appreciated,
James

Ruby is a dynamic language, as David pointed out, you can always get
around
whatever someone does. I think the point isn't so much to make it
impossible
for them to do something, but rather to make it clear how it was
anticipated
that it would be used. If they want to go so far as to override the
methods,
or perform instance_eval to get at the variable, then I'd take that as
a
very deliberate effort, so due to their determination to get around
your
design, I would just assume that they had a legitimate reason to do so,
or
at least if it blows up, they'll have no cause to be upset with you for
it.
=20
I don't know how you are trying to use the class, that you feel the
need to
return an array that cannot be altered, but you could define methods
which
give this functionality without ever exposing the array itself,
something
like this:
=20
=20
# consider defining methods to give the functionality you might want
# without exposing the guts of your class to the world
class Configuration
def initialize() @dependencies =3D [] end
def add_dependency(d) @dependencies << d end
=20
def each_dependency
@dependencies.each { |dep| yield dep }
end
end
=20
config =3D Configuration.new
config.add_dependency :dependency1
config.add_dependency :dependency2
config.add_dependency :dependency3
=20
config.each_dependency do |dependency|
puts "I am accessing #{dependency}, " \
"without ever seeing the array."
end
=20
=20
=20
# Of course, they can always get around whatever you have done,
# in the above, there is no way to get at @dependencies from the
# outside world, but in their code they could just add the code below
class Configuration
attr_accessor :dependencies
end
=20
p config.dependencies
=20
__END__
Ruby is not about strict rigid code, or forcing people to use it
a certain way, it is dynamic. You have made your intentions clear,
at this point, if the user is not satisfied with your intentions,
then you must trust them to know what is best for their needs.
Something like this will not occur by accident, they have quite
deliberately decided that they need to break the encapsulation.

Thanks for the answer - appreciate it, and have taken it on board.