On Wed, 07 May 2008 15:48:56 +0200, Igor Stasenko wrote:

> 2008/5/7 Klaus D. Witzel :
>> 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.

Didn't mean better/worther; mentioned nil initializing only because this  
can be done in *every* programming language which deserves the *language*  
attribute ;-) thereby ignoring the language designer's good wishes ;)

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

Hhm. what's that mean.

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

Unless a language designer puts inheritance into the developer's hands and  
promises that the language then still provides  
modularity+messaging+you_name_it (unlike Squeak/Smalltalk which doesn't  
implement anything related to modularity nor slots).

I think that Newspeak language design is one approach, Squeak/Smalltalk  
implementation is another.

> For instance: useful case - omit calling superclass initialization.

Not possible in Newspeak, since by *naming* the superclass (at the  
"declarative" time of subclassing) in Newspeak one *must* also name  
super's constructor (the *static* symbol that I reflected upon in the  
above and again in the next sentence), or else accept the default one  
(#new); similiar to how it is in Javanese ;)

FWIW, the superclass' slot name can be anything (message based, of course)  
but, the constructor's message selector is the *static* thing that user of  
a module has to know about ...

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

Didn't understand a word :( what has *state* to do with a scope-bound  
privilege? Can you reformulate using a) global visibility of a slot v.s.  
b) ... v.s. c) ... v.s. x) local visibility of a slot. TIA.

>
>>
>> > 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 :)

Congratulations ;)

>
>>  /Klaus
>