[Setools] What we have yet

[Klaus D. Witzel]

Hi Alex,

on Sun, 25 Jun 2006 16:45:11 +0200, you wrote:

> Hi Klaus!

Thank you Alex for redirecting my post :)

>> I'm interested in better (not necessarily faster) prototyping, in the  
>> sense of drafting new or refining existing software at the draft level,  
>> with full support of a running+reflexive system (and of DNU, of course  
>> :)
>
> Do you have an idea of what is currently missing in Squeak ?

Sure. But I have to picture it, or else too many words will blur it. A  
starting points is, and my colleague in UBS agrees fully, a rewarding  
system for re-use. Simply that. We know that we cannot penalize non-reuse,  
don't we. What are the tools which tell me: don't go any further Klaus,  
*this here* is already available for you to reuse. How shall I ask, how  
formulate a query. Google is of no help here, so we must invent.

>> I also want to see diff's of a draft against what is already  
>> implemented, in a nice GUI. A good draft is > 20 pages and is  
>> impossible to review together with the customer (user) by using system  
>> / OB / etc browser alone.
>
> What  kind of navigation tool would you need?
> Do you mean something more graphical?

Almost same problem as above (need picture instead of words) but an  
aproximative example is Shout combined with diffing (roughly speaking).  
Perhaps an intelligent workspace, in which class definition and method  
definition is a by-product?

>> And as already was posted in the "Better write a test or a comment for  
>> a given method?" thread in squeak-dev, I'd like to see better support  
>> for tests (don't care on the syntax level). Examples: test 1 is related  
>> to test 2 by this and that; a method is no longer accepted if a test  
>> fails; etc.
>
> Omnibrowser enables extensions to be quickly written and added. This is  
> why it is important to push OB.

Sure, agreed. But let me give an example problem area which cannot be  
addressed by extending OB. Let's say we have to deveop three methods,  
isUnaryToken, isBinaryToken and isKeywordToken. The tests for them must  
satisfy
  isUnaryToken not or: isBinaryToken not.
  isUnaryToken not or: isKeywordToken not.
  isBinaryToken not or: isKeywordToken not.
(note that there is not need for []'s in test clauses).

How shall the problems arising from symmetry and neverending recursion in  
these three simple example statements be addressed?

> Cheers,
> Alexandre

/Klaus