True, the statement above was related to the part you deleted
in your answer.
cheers
Simon
-----Original Message-----
From: azrael@cream.org [mailto:azrael@cream.org]
Sent: Thursday, April 13, 2006 11:36 AM
To: ruby-talk ML
Subject: Re: Equivalent of Java static code block in Ruby?> Maybe i don't understand but i think this is plain wrong:
>
> class A
> puts "Hello"
> end
>
> 100.times do
> a = A.new
> end
>
> #=> Hello
>No, that is what I would expect. Anything else is broken.
Martin
>
> No, that is what I would expect. Anything else is broken.
>
> MartinTrue, 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
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, azrael@cream.org <azrael@cream.org> wrote:
> >
> > 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...
endAs a suggestion?
Martin
Why? Why add MORE syntax to solve a non-problem? This would also require
--
===Tanner Burson===
tanner.burson@gmail.com
http://tannerburson.com <---Might even work one day...
>
> 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
> >
> > 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
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.
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
On 4/13/06, azrael@cream.org <azrael@cream.org> wrote:
--
===Tanner Burson===
tanner.burson@gmail.com
http://tannerburson.com <---Might even work one day...
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, Tanner Burson <tanner.burson@gmail.com> wrote:
On 4/13/06, azrael@cream.org <azrael@cream.org> wrote:
> > >
> > > 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
> 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.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
--
===Tanner Burson===
tanner.burson@gmail.com
http://tannerburson.com <---Might even work one day...
--
===Tanner Burson===
tanner.burson@gmail.com
http://tannerburson.com <---Might even work one day...
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
>
> 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.
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
On 4/13/06, azrael@cream.org <azrael@cream.org> wrote:
--
===Tanner Burson===
tanner.burson@gmail.com
http://tannerburson.com <---Might even work one day...
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 4/13/06, azrael@cream.org <azrael@cream.org> wrote:
>
> 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
Non-static initializers of instance variables too. Teh usual.
Martin
On Fri, Apr 14, 2006 at 01:26:24AM +0900, Tanner Burson wrote:
On 4/13/06, azrael@cream.org <azrael@cream.org> wrote:
>
> >
> > 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.Other than code inside of methods what are you referring to?