> 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 ?)
Yes!
> 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 ?
But contracts and pre and cons are not linked with 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...
No this is not only that is that if you have precondition you localize
the origin
of bugs.
> 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.
I'm not sure that this is what I implied. For me pre and post are a
nice way to
specify the responsibility of the caller and the callee.
> 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.
I agree.
I would avoid to have
self assert: [aParam isKindOf: Point]
> 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'.
I would prefer to have
[p isStringable]
string implements Stringable
Text implements Stringable
I think that this is not because we have a dynamically typed language
that we should forget
consistent/compatible types (expressed via an agreement on common
protocol).
> Maybe you have some better ideas about optional types as a
> specification...
> Semi-automatic RoelTyper like helper tools?
Do not confuse preconditions and type annotation. For me precondition
is also about
the object state before the method execution.
So what we should do is learn what could be good.
Stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
