end
Martin
True, the statement above was related to the part you deleted
in your answer.
cheers
Simon
No, that is what I would expect. Anything else is broken.
Martin
True, the statement above was related to the part you deleted
in your answer.
My apologies; just being a bit trigger happy. I didn’t actually know if
it was right, I was just saying that I would expect any other behaviour
broken.
Still, some clarificatory syntax might not be a bad thing. Perhaps a
@@do
…static initializer stuff…
end
As a suggestion?
Martin
On 4/13/06, [email protected] [email protected] wrote:
My apologies; just being a bit trigger happy. I didn’t actually know if
Martin
Why? Why add MORE syntax to solve a non-problem? This would also require
you to put all you attr_* calls in this new syntax, as well as calls to
private :method. I vote (as if it would matter) for documentation
being
written, not new syntax.
On 4/13/06, Tanner B. [email protected] wrote:
private :method. I vote (as if it would matter
including the method definitions. What would you want to happen if you
class definition gets executed when the class is loaded. There’s the
Martin
To further illustrate my point that you’re trying to create an
artificial
separation where none exists, here are 3 of the more common class level
declaration or initialization statements:
irb(main):009:0> Class.private_methods.include? “attr”
=> true
irb(main):010:0> Class.private_methods.include? “private”
=> true
irb(main):011:0> Class.private_methods.include? “include”
=> true
All of which, are simply method calls, no different than any other
“executive” code.
–
On 4/13/06, [email protected] [email protected] wrote:
think of the top-level class block to be for declarations and
initialization of members belonging to the class, not random “executive”
code, per se.
Except that really all of the code in a class is executed at “load
time”,
including the method definitions. What would you want to happen if you
re-opened a class? Should it go back and re-load your static
initializer
code, or ignore it?
By putting class-load-time execution into some kind of static
constructor,
it
cleans up that division of responsibility a bit, and produces a
marginally more literate bunch of code.
What division of responsibility? Currently it’s divided, all code in a
class definition gets executed when the class is loaded. There’s the
division. This has messy implications for the attr_* family of methods,
as
well as private/public/protected :method as well. Where would you place
these? Would they go in your static block, or outside of it? What
about
the private/public/protected method calls, they need to be after the
method
definition, so towards the end of the class, how do you handle those?
Do
you consider these part of the class definition or “random executive
code”?
I think all you would do by adding another division here, is confuse
matters. Currently I think it’s pretty clear.
Martin
I think all you would do by adding another division here, is confuse
matters. Currently I think it’s pretty clear.
I think I agree with you. One shouldn’t do stuff simply because that’s
the way Java does it. If anything, quite the opposite.
Although, it’s not true that all code in a class is executed at class
load time. Most of the code typically will only be called on
instantiation of an object, and sometimes it’s helpful not to mix the
two up too thoroughly.
Martin
On 4/13/06, [email protected] [email protected] wrote:
load time. Most of the code typically will only be called on
instantiation of an object, and sometimes it’s helpful not to mix the
two up too thoroughly.
Other than code inside of methods what are you referring to?
irb(main):031:0> class Blah
irb(main):032:1> attr_reader :asdf
irb(main):033:1> end
irb(main):034:0> p Blah.instance_methods.include?(“asdf”)
true
Martin
Why? Why add MORE syntax to solve a non-problem? This would also require
you to put all you attr_* calls in this new syntax, as well as calls to
private :method. I vote (as if it would matter) for documentation being
written, not new syntax.
Maybe it’s a Javaism that’s deeply engrained in my consciousness, but I
think of the top-level class block to be for declarations and
initialization of members belonging to the class, not random “executive”
code, per se.
By putting class-load-time execution into some kind of static
constructor, it
cleans up that division of responsibility a bit, and produces a
marginally more literate bunch of code.
Martin
On 4/13/06, [email protected] [email protected] wrote:
instantiation of an object, and sometimes it’s helpful not to mix the
two up too thoroughly.Martin
Actually the code in those method bodies is executed – that is what
defines the methods.
Think about this (very silly) sample code:
class Foo
if (Time.now.to_i % 2).zero?
def bar
puts “Even time”
end
else
def bar
puts “Odd time”
end
end
end
f = Foo.new
f.bar
Note that it does not matter when you call bar, but when the class is
loaded…
pth
On Fri, Apr 14, 2006 at 01:26:24AM +0900, Tanner B. wrote:
Although, it’s not true that all code in a class is executed at class
load time. Most of the code typically will only be called on
instantiation of an object, and sometimes it’s helpful not to mix the
two up too thoroughly.Other than code inside of methods what are you referring to?
Non-static initializers of instance variables too. Teh usual.
Martin