Forum: Ruby Re: Equivalent of Java static code block in Ruby?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
87e9a89c53ccf984db792113471c2171?d=identicon&s=25 Kroeger, Simon (ext) (Guest)
on 2006-04-13 14:48
(Received via mailing list)
> > end
> Martin
True, the statement above was related to the part you deleted
in your answer.

cheers

Simon
D2ce3fc131413e4456054ea24efcca0e?d=identicon&s=25 unknown (Guest)
on 2006-04-13 15:19
(Received via mailing list)
> >
> > 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
A777f1a2049d78a12ead38efb8f75f97?d=identicon&s=25 Tanner Burson (Guest)
on 2006-04-13 15:28
(Received via mailing list)
On 4/13/06, azrael@cream.org <azrael@cream.org> 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.
D2ce3fc131413e4456054ea24efcca0e?d=identicon&s=25 unknown (Guest)
on 2006-04-13 15:34
(Received via mailing list)
> >
> > 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
A777f1a2049d78a12ead38efb8f75f97?d=identicon&s=25 Tanner Burson (Guest)
on 2006-04-13 17:03
(Received via mailing list)
On 4/13/06, azrael@cream.org <azrael@cream.org> 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
A777f1a2049d78a12ead38efb8f75f97?d=identicon&s=25 Tanner Burson (Guest)
on 2006-04-13 17:10
(Received via mailing list)
On 4/13/06, Tanner Burson <tanner.burson@gmail.com> wrote:
> > > private :method.  I vote (as if it would matter ;) ) for documentation
> 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.

--
D2ce3fc131413e4456054ea24efcca0e?d=identicon&s=25 unknown (Guest)
on 2006-04-13 17:16
(Received via mailing list)
>
> 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
A777f1a2049d78a12ead38efb8f75f97?d=identicon&s=25 Tanner Burson (Guest)
on 2006-04-13 18:28
(Received via mailing list)
On 4/13/06, azrael@cream.org <azrael@cream.org> 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
2c51fec8183a5d21c4e11b430beabb47?d=identicon&s=25 Patrick Hurley (Guest)
on 2006-04-13 19:11
(Received via mailing list)
On 4/13/06, azrael@cream.org <azrael@cream.org> 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
D2ce3fc131413e4456054ea24efcca0e?d=identicon&s=25 unknown (Guest)
on 2006-04-13 19:27
(Received via mailing list)
On Fri, Apr 14, 2006 at 01:26:24AM +0900, Tanner Burson 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
This topic is locked and can not be replied to.