__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code)

[Kay Schluehr]

Reinhold Birkenfeld schrieb:
> Kay Schluehr wrote:
> > Dan Sommers schrieb:
> >
> >> How about this:
> >>
> >>     def __init__(self, self.x, y, self.z):
> >>         # self.x, self.z from first and third explicit parameters
> >>         do_something_with_y()
> >
> > Can you tell me in which way it is anyhow better than the original
> > proposal
> >
> >      def __init__(self, .x, y, .z):
> >           # self.x, self.z from first and third explicit parameters
> >           do_something_with_y()
> >
> > besides that it is more verbose?
>
> It is more explicit. Explicit is better than implicit.

The punctuation syntax makes it explicit too. But maybe a point is a
more tiny and less explicit symbol than an @ that makes a decorator
explicit ;)

> But as with many proposals, this raises consequential questions, for
> example, how "self.x" parameters are handled in other methods, or even
> functions, as __init__ is not special-cased by the parser.
>
> Reinhold

Yes. My argument against the syntax is more that of a language lawyer:
how a class uses the argument parameters of a constructor is an
implementation detail of a class and should not be published in the
constructor interface.

One may assign special attributes to the classes ( e.g. tagging it with
a metaclass ) or a qualifier. I had recently a look on Scala an
object-functional language running on top of the JVM. Scala introduces
the concept of a "case class" to represent object trees. All arguments
passed into a case class constructor become automagically object
attributes. This is for convenience and let the tree grow if the passed
arguments are case class instances again. Here it is the class type
that determines how it's construction is handled. I think this is a
reasonable approach. 

Kay