Hehe, yes, once I implemented a matlab like generalized access: m(1) = 3.14; % single element m(1:5) = [2 3 9 7 1]; % a contiguous subspace m([1 2 5]) = -m([1 2 5]); % an arbitrary subspace m(:) = m(end:-1:1); % a whole subspace (colon = column matrix) m( m>2 ) = m( m> 2 ) - 2; % a mask of booleans m( m<0 ) = 0; % variant: fill a subspace with an element m( m>5 ) = []; % a remove operation
To keep it extensible and avoid static type checks, i ended up with triple dispatching... Not the code I'm the most proud of. I must admit a static-type compiler can handle such situations better... Maybe some declarative rules rather than procedural would also help... Nicolas 2009/10/20 Dale Henrichs <[email protected]>: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
