2009/10/16 Stéphane Ducasse <[email protected]>:
>
>> I think Smalltalk quality is based on a completly different plane
>
First, my reference about quality is not Squeak, I rather mean st-80
from ParcPlace :)
At least it used to have
- more generous class and method comments
- less bugs and obscure code (certainly because less code too !)
- a certain homogeneity (less programmers ?)
So were is the Smalltalk quality ?
- the ability to test code as soon as written
- the ability to write small and simple code,
- the ability to write readable code,
- the ability to extend code
Are these essential properties in the quality standards used in static typing ?
> You mean not checkable documentation, absence of documentation,
> lack of static typing to document (because what would be good is to
> have a pluggable type system)
>
I agree, lack of type can be seen as a weakness for documenting APIs.
As a workaround, we use funny parameter names (anArrayOfStrings).
Or we add a method comment (hem... at least we should).
I agree, all these comments will become false when code is changed,
and the quality will decrease...
As false as an outdated assertion... but silent... Maybe it's worse ?
Browsing senders, or inspecting the signature of message sent to, or
inserting a halt is sometimes our solutions...
I agree, this is not ideal.
So yes, assertions as a public declaration of API could be good for documenting.
And a good description of assertion failure can also provide
informative feedback to the user (more than a Debugger ?)
What I do not like is defensive assertions as a potential barrier to
extendability, because they correspond to a static view of code, a
snapshot of current state.
Smalltalk state does and will change. The image is living, and class
structure not written on stone.
Rapidly changing code is definitely not accepted as a quality standard...
In a rapidly changing image, assertions could be a supplementary drag
against change...
Suppose I have a method accepting a String parameter P: p.
[p isString] assertWithDescription: 'method xxx only accept a
String as parameter P'.
Now maybe the method would have worked with a Text. I have been too restrictive:
[p isCharacters] assertWithDescription: 'method xxx only accept characters'.
Now someone introduce WideString, and my code only work with ByteString.
[p isCharacters and: [p asString isByteString]]
assertWithDescription: 'method xxx only accept byte characters'.
Yes, but the method does not work with empty String, I add:
[p notEmpty] assertWithDescription: 'method xxx only accept non
empty strings'.
Nor does it with some control characters:
self assertPHasValidCharacters: p.
Fortunately someone then correct the WideString case, now I can
retract isByteString.
Unfortunately, p will be stored in an inst. var. with many public interfaces...
Each time, I have to change all the false assertions in all senders of
the core method that are in the public API...
And maybe some of these public APIs are driven by other public APIs
(you meet this in Smalltalk, didn't you?)
To avoid this I create a specific method
assertPIsValid: p
| sender |
sender := thisContext sender homeContext selector.
[p isCharacters] assertWithDescription: 'method ' , sender , '
only accept characters'.
[p asString isByteString] assertWithDescription: 'method ' ,
sender , ' only accept byte characters'.
[p notEmpty] assertWithDescription: 'method ' , sender , ' only
accept non empty strings'.
self assertPHasValidCharacters: p from: sender.
But now, I can't see the assumption from within public API. I have to
browse implementors of assertPIsValid:, so I loose the immediate
documentation...
And one day, a brilliant programmer decide a ReadStream on characters
would also be a good parameter P, with a minor change in the core
method...
Arghh, I don't want to advance the stream yet and do all my static checks...
In order to maximize extendability, can't we use extensible assertions
like sending a message?
If we end up with
[p isAGoodParameterPForMyMessage] assert.
then I don't buy it ;)
Maybe you have some better ideas about optional types as a specification...
Semi-automatic RoelTyper like helper tools?
Nicolas
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
