I’ve seen so far, that a ruby method can be hacked to be
“unchangeable”.
Will ruby some day support some kind of predicate or modifier, so I can
protect my method beeing overwritten?
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
I’ve seen so far, that a ruby method can be hacked to be
“unchangeable”.
Will ruby some day support some kind of predicate or modifier, so I can
protect my method beeing overwritten?
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
I’ve seen so far, that a ruby method can be hacked to be
“unchangeable”.
Will ruby some day support some kind of predicate or modifier, so I can
protect my method beeing overwritten?
Gergo
How would your method get overwritten anyway? (I know it’s possible, so in
some sense it’s a rhetorical question, but by answering it we can discuss some
design philosophies.)
I have some sympathy for your concern, but I have learned to adopt the
following attitudes:
if other people overwrite my method, that’s their business; the
warranty is void
if I overwrite my own method accidentally, I either have a messy
design, a bad approach, or a small brain
Will ruby some day support some kind of predicate or modifier, so I can
protect my method beeing overwritten?
Why would you want that?
Because I want to protect everyone (including myself) to overwrite some
methods of my object.
Or should I design it bad? Should I split this object into two
objects, one for the “from-the-self methods” and one for the
user-defined methods?
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
The whole nature of Ruby would have to be changed if this feature was
added to it. And all you would have is Java by another name.
and this is universal problem to any question, where someone don’t
know the answer
right answer is that this can be done with hack, and so don’t need to
be added to language core. same as private/public “keywords” is really
just methods written in ruby itself. of course, this hack will not
guarantee against another hack that rehack this hack due to
dynamic character of language
How would your method get overwritten anyway? (I know it’s possible, so in
some sense it’s a rhetorical question, but by answering it we can discuss some
design philosophies.)
Singleton methods in an object, which is derived from a kind of template
class, which has some method, which does some tasks, but relies on
defining some methods. (callbacks)
But there must be some easier situations…
I have some sympathy for your concern, but I have learned to adopt the
following attitudes:
if other people overwrite my method, that’s their business; the
warranty is void
Well, but it is nice, if you warn them with an exception…
if I overwrite my own method accidentally, I either have a messy
design, a bad approach, or a small brain
Programmers are LAZY and have NO ((big)) brain. That’s why they can
work. So your reasoning is not fair
Gergo
±[Kontra, Gergely @ Budapest University of Technology and Economics]-+
How would your method get overwritten anyway? (I know it’s possible, so in
some sense it’s a rhetorical question, but by answering it we can discuss some
design philosophies.)
I have some sympathy for your concern, but I have learned to adopt the
following attitudes:
if other people overwrite my method, that’s their business; the
warranty is void
if I overwrite my own method accidentally, I either have a messy
design, a bad approach, or a small brain
For what it’s worth, that was the same revelation that made me stop
compulsively checking argument types in my ‘utility’ classes. I
decided that I was doing inherently single-programmer stuff, and
anyone else using the class would also be doing single-programmer
stuff; there would never be an issue of, say, two people independently
modifying code in the same runtime program. Therefore, there was a
definite ‘end user’ programmer, and it was up to them to see that all
their arguments had the proper functionality. Saved a lot of useless
(and ugly) ifs and asserts.
“K” == Kontra, Gergely kgergely@mlabdial.hit.bme.hu
writes:
Because I want to protect everyone (including myself) to
overwrite some methods of my object.
Freeze your class
pigeon% ruby -e ‘class A; def a() end end; A.freeze;class A; def
a() end end’
-e:1: can’t modify frozen class (TypeError)
pigeon%
I think that what he’s wanting to do is freeze a method, not a whole
class…
-austin
– Austin Ziegler, austin@halostatue.ca on 2002.10.14 at 13.10.54
The whole nature of Ruby would have to be changed if this feature was
added to it. And all you would have is Java by another name.
Admit it: you’re learning ‘test/unit’ and are waiting a green bar on
assert_equal(limit, people.patience).
i think that answers “whole nature of ruby would have to be changed”
have no meaning. as you can see in this particular case, “whole nature
of ruby” already include such feature for entire class/module. so i
will laugh each time when i see such argument
