In C++ private members is inacessable to derivatived classes.
I want the same, but with a extra twist.
Instances declared in the parent should be readonly(frozen) to the
subclass.
So that the subclass (B):
is allowed to read the variable.
is disallowed to write to the variable (raise exception).
Offhand, I’d say it wasn’t even hackable in pure ruby, because
[snip]
I am sad to hear that. Then I have to learn to live without protection.
Thanks Guy+Martin for the discussion it has been educational.
BTW: Perhaps it could be nice if you could say:
class A
def initialize @value = [1, 2, 3]
end
subclass_freeze :value # maybe nice to have ?
end
–
Simon Strandgaard
–
([ Kent Dahl ]/)_ ~[ Kent Dahl - Kent Dahl ]/~
))_student_/(( _d L b_/ (pre-) Master of Science in Technology )
( __õ|õ// ) )Industrial economics and technological management(
_/ö____/ (_engineering.discipline=Computer::Technology)
I am sad to hear that. Then I have to learn to live without protection.
Thanks Guy+Martin for the discussion it has been educational.
You’re welcome - it’s been educational for me too.
BTW: Perhaps it could be nice if you could say:
class A
def initialize @value = [1, 2, 3]
end
subclass_freeze :value # maybe nice to have ?
end
This is probably hackable, with some judicious delving into Module and
hooks. But you can only freeze an object, not a variable, so it would
prevent @value << [foo] in a subclass, but not @value = bar
As a fellow C++ refugee, I’ve found that while Ruby doesn’t support all
C++'s constructs, there’s usually an equivalent way to do any given
problem, and it almost invariably feels better
Actually, I’m still not perfectly clear on what you want. Is it a
variable whose value can be mutated in any methods you write inside
class A, but which client programmers writing classes that inherit from
A can only treat as a constant? How about if they call a method from A
which changes the value of @value? What if they override @initialize and
don’t call super - how does the value get set, then? And don’t forget
they can simply reopen A and add a method of their own, then call it
from B.
class A
def initialize @value = [1, 2, 3]
end
subclass_freeze :value # maybe nice to have ?
end
This is probably hackable, with some judicious delving into Module and
hooks. But you can only freeze an object, not a variable, so it would
prevent @value << [foo] in a subclass, but not @value = bar
Is it a variable whose value can be mutated in any methods you
write inside class A, but which client programmers writing classes that
inherit from A can only treat as a constant?
Yes. Any method within A is able to read+write (mutable).
Subclasses of A is only able to read (imutable).
If subclasses attempt to write they die.
How about if they call a method from A which changes the value
of @value?
Subclasses should be allowed to call a superclass-method, which does make
changes.
What if they override @initialize and don’t call super - how does
the value get set, then?
I don’t know which kind of behavier would be appropriate here?
And don’t forget they can simply reopen A and add a method of their own,
then call it from B.
I consider 'reopen’ing as a kind of subclassing. if subclass then its
readonly mode
···
On Wed, 25 Jun 2003 14:22:56 +0000, Martin DeMello wrote:
And don’t forget they can simply reopen A and add a method of their own,
then call it from B.
I consider 'reopen’ing as a kind of subclassing. if subclass then its
readonly mode
I seriously doubt you can write a Ruby program capable of distinguishing
between
[snip}
In fact, if there weren’t so many ingenious people on the list, I’d go
ahead and flatly say it was impossible
Well, reopening is a grey area… not strictly important to me.
What is most interesting for me, is if you such protection works with
inheritance. But I doubt its possible, when reading this thread.
Again if there is any experts, who know something we others dont, then say
something
···
On Wed, 25 Jun 2003 21:45:12 +0000, Martin DeMello wrote:
