Signature Revealing Naming Convention
for Smalltalk (SRNC-ST v. 2.001)
is available at:
http://members.fcc.net/panu/4rules.htm----------------------------------------------
The main innovation of revision 2.001 is its support
for 'Dynamic Interfaces'. These are declared with the
help of State-Change-Expressions (SCE) of form:
self NextState: #{The name of an interface class}.
This means that instead of preconditions on
a validity of an interface you can model
the state-chart of an object's signatures
explicitly.
For instance, the method #pop of Stack can
be declared as:
pop
(self size = 1)
ifTrue: [self NextState: #EmptyStack]
ifFalse:[self NextState: #Stack].
...
instead of the more conventional:
pop
self assert: [self isEmpty not ].
....
What's the difference ? Categorizing the possible
dynamic states of an object's interface is a natural
way of characterizing an object's states succinctly.
For instance even though a Stack of size 2 is in a
different 'state' than a stack of size 529, they are
in the same 'signature state'. The difference between
their states is smaller than the difference between
Stacks of size 1 and 0 (the last one can't be sent
the message #pop).
A quote from
http://members.fcc.net/panu/SRNC-ST.htmexplains:
...
Note the general Object-Oriented principle at work:
Instead of defining a single method that tests for
the type of the current object, each (Object-Oriented)
class can define its own polymorphic version of the
method. In SRNC, instead of defining a single
interface-signature with lots of tests and
preconditions on its validity, we can define a
separate signature for each state. As a by-product
we get a formal definition of the state-chart
of the object.
...
Comments and feedback welcome !
Thanks
Panu
Locked
