[squeak-dev] Re: talk on Newspeak online
Igor Stasenko
siguctua at gmail.com
Thu May 8 02:56:11 UTC 2008
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.
More information about the Squeak-dev
mailing list
|