2008/5/7 Klaus D. Witzel <klaus.witzel at cobss.com>:
> On Wed, 07 May 2008 10:22:46 +0200, Igor Stasenko wrote:
>
>
> > I read Gilad's blog and having some concepts which i think is
> > redundant and smell like javaisms.
> >
>
>  ;)
>
>
> > For instance, i don't share the view, that all fields in class
> > instance should be initialized and initialized once, by constructor
> > (instance factory method).
> > What about lazy initialization?
> >
>
>  Lazy in the sense of, a) initialize them with nil [in the constructor] then
> later b) assign them anything else? That's always possible, isn't it. I
> don't see much a problem here, except the *cause* of such language design
> decision.

So, instead of polluting code with initializers (__which is optional__)
as in Damien's note:

Person class>>name: aString birthdate: aDate
 ^ self new
        name: aString;
        birthdate: aDate;
        yourself

they proposing to pollute code with nil initializers everywhere
(__which is mandatory__)?
I don't see how latter is better than smalltalk.

>The latter is concerned with 1) modularity-ness of each and every
> constituent 2) non-staticness of each and every constituent and 3)
> mixin-able-ness of every class (aka behavior-bearing object). To highlight
> just one problem in this >= 3 dimension time-space, which AFAICT is not
> solved yet (or perhaps just not published yet) in Newspeak: its
> *constructor* selector (the symbol) is for sure a *static* symbol
> constituent, violating non-staticness desideratum ... that is to say, even
> in a very-highly modularized Newspeak system you have to know the
> constructor message name of the things you import/mixin so, what about when
> they are changed behind your back ? (in a library you use, for example)
>
>  ...

To me it looks like people see a fallen tree across the road here.
I don't see much problem with smalltalk's approach. Proper
initialization will be always a concern of developer. There is no way
how we can ease his task with language sugars/semantics, because there
always can be cases, which don't fit to developer's plan of how things
needed to be initialized. So, the less we constrain him here - the
better.
For instance: useful case - omit calling superclass initialization.

>
>
> > Declaring private/public fields looking redundant too: they should be
> > always private.
> >
>
>  Except when you do not want to disappoint the zillions of flies around you?
> (who, by "law of gravity", cannot err ...)
>

I don't see how message-driven design (which Newspeak claiming is)
should care about declaring state properties.
State in message-driven system is a behavioral component, not declarative one.

>
>
> > Instead, accessors #foo, #foo: can be made public or private by the will.
> > But if you make field public, then it's accessors became public as
> > well? But what if i want #foo to be public, but #foo: to be private?
> >
>
>  This is not a valid question for obtaining a Certified Javanese credit! You
> failed ! ;)
>

I don't need Certified Javanese credit :)

>  /Klaus
>


-- 
Best regards,
Igor Stasenko AKA sig.