------art_21334_10756905.1144940569189
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 ;) ) 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.


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...

------art_21334_10756905.1144940569189--