Nicolas, many very good points. Just to add food for thought... double dispatching is a technique that has the benefit of avoiding isXXXX messages completely allowing for maximum flexibility and if the message isn't understood, immediate feedback that the programmer has done something wrong (which can be fixed by implementing the appropriate dispatch method) ... better than an assertion failures perhaps...
Of course, double dispatching is not without it's drawbacks. I prefer double dispatching to implementing isXXX messages, but then I'd like to eliminate Booleans, too:) Dale ----- "Nicolas Cellier" <[email protected]> wrote: | 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
