2008/5/8 Vassili Bykov <smalltalkbigot at gmail.com>:
> I have considerable experience programming in both Smalltalk and
>  Newspeak, and (despite my email address) I'll say that Newspeak is an
>  improvement in a number of aspects. That includes constructors.
>
>  The knee-jerk reaction of "X is crap because $(language_name) which
>  has X is crap" can prevent you from seeing the nature of the issue. It
>  helps to understand what X gives and what it takes away. Also, the
>  particular X can be quite different from X in $(language_name).
>

Mandatory field initialization is good!
But this is not true in C++ : initialization of fields with intrinsic
types are optional, which always a source of errors and ruining the
whole
concept.

class X {
   int x;
   int y;
  X(int _x) x(_x) {};    // y left uninitialized, compiler don't
cares, users cry in pain
}

>  What we are talking about here is _instance creation discipline_. Like
>  any other discipline, it eliminates some freedoms in the interest of
>  order and predictability. The question is always whether the gains of
>  the latter compensate for the loss of former. I imagine 30 years ago
>  there were people decrying the loss of goto and the freedom it brings.
>
>  Here is what disciplined instance creation brings:
>
>  1. Better class usability. The first question one has when looking at
>  an unfamiliar class is "how do I use it?". The next one is often "how
>  does it work?" Answering both depends on knowing how an instance is
>  created and initialized. A Newspeak class declaration always provides
>  the answer. In contrast, in Smalltalk you can only guess what instance
>  creation messages can produce a valid instance. Presumably, the ones
>  in the class will. Maybe the inherited ones too. At least some of
>  them. Or will they?
>

All in hands of initial developer. If he wants to make life easy for
users - he's not putting dozens of instance creation methods at class
side,
or does this in a manner, which is easy to understand. This problem
lies in social plane (good documentation, good design e.t.c.), rather
than purely language related.


>  2. Assurance that the instance you get is initialized properly as
>  intended by the class author.
>
>  3. Easier change management. When I need to add a Boolean flag to an
>  instance, I add one line to the class saying
>
>    isFoo ::= false.
>
>  This is the only change, other than actually using the flag, to ensure
>  that the slot is there and properly initialized in all instances. I
>  don't need to add a word to the class declaration to declare the
>  variable, and then hunt down all possible initialization methods (what
>  are they? did I cover all of them?) to ensure the initial value is
>  always set. Furthermore, as the system mutates the existing instances,
>  it can use this new declaration to initialize the slot in the old
>  instances to at least have a value of proper type.
>
>  In my experience, all of the above are significant benefits that make
>  it easier to build reliable programs.
>
>  On a more philosophical note, whether a "language shouldn't care or
>  enforce rules aka 'constructors'". A language should help the
>  developer use its facilities. Some rules and the structures they
>  enforce may be helpful, even if they are not part of the language
>  core. Objects are the primary facility of Smalltalk/Newspeak, and
>  their creation is a common operation. Proper initialization is indeed
>  concern of a developer, but it *can* in fact be eased with language
>  semantics. Again, this is not a hypothetical proposition, this is my
>  experience report.
>
>  As for the "useful" case of skipping superclass initialization--again,
>  goto proponents had various use cases of how indispensable it was. The
>  two cases are not that far from each other. You lose some
>  capabilities, but in the larger picture of writing more predictable
>  software the loss is more of a "good riddance" to the ability to
>  introduce non-local idiosynchrasies.
>

.. or introduce pain because of inability to make things in a way how
developer sees it.


>  Regarding "static constructor messages", I fail to see the problem. A
>  message name is static by its nature, in that it is a human-readable
>  reference to a certain behavioral contract. A "+" refers to a contract
>  promising to perform an addition-like operation. "x:y:" refers to a
>  contract to create a vector-like entity from components that carry a
>  certain meaning. Patterns for adapting contracts with mismatching
>  names have long existed, and can be applied to instance creation as
>  well as they have been elsewhere.
>

About constructors.

It is really easy to maintain same discipline in smalltalk.
Maybe its hackish, but its possible to implement w/o changing syntax:

MyStrictClass>>new
   self checkConstructor.
    ^ super new

MyStrictClass>>checkConstructor
   | sender |
   [ sender := thisContext sender. sender sender receiver == self ] whileTrue.
    self assert: (self validConstructors includes: sender method selector )

MyStrictClass>>validConstructors
   ^ ( #new )

MyStrictSubClass>>x: aX y:aY
   ^ super new x: aY; y: aY; yourself.

MyStrictSubClass>>validConstructors
   ^ ( #x:y: )

MyStrictSubClass2>>validConstructors
   ^ ( #x:y: #new )  "allow constructors from superclass and from
superclass superclass"


>  Cheers,
>
>  --Vassili
>
>



-- 
Best regards,
Igor Stasenko AKA sig.