Smalltalk report

Hi,

it seems Smalltalk Report archives are not accessible anymore. Does one
of you have copies ? I would like to access "Smalltalk Report, 2(7), May
1993".


Thank you very much


--
Damien

which article?

On 14 août 06, at 09:53, Damien Cassou wrote:

stéphane ducasse wrote:
> which article?

Hi Stephane,


somebody in Dortmund already answered and will scan the article for me.
For information, here are the two articles I would like:

Kent Beck. Instance specific behavior: Digitalk
implementation and the deep meaning of it all. Smalltalk
Report, 2(7), May 1993.

Kent Beck. Instance specific behavior: How and Why.
Smalltalk Report, 2(7), May 1993.


Thank you Stephane



--
Damien

read my joop paper. This is better explained. But I will send you the  
paper so that you can compare :)

Stef

On 14 août 06, at 10:32, Damien Cassou wrote:

On 14.08.2006, at 10:47, stéphane ducasse wrote:

> read my joop paper. This is better explained. But I will send you  
> the paper so that you can compare :)
>


And have a look at BehaviorTest>>#testChange

testChange
        "self debug: #testChange"

        | behavior model |
        behavior := Behavior new.
        behavior superclass: Model.
        behavior setFormat: Model format.
        model := Model new.
        model primitiveChangeClassTo: behavior new.
        behavior compile: 'thisIsATest  ^ 2'.
        self assert: model thisIsATest = 2.
        self should: [Model new thisIsATest] raise: MessageNotUnderstood.

stéphane ducasse wrote:
> read my joop paper. This is better explained. But I will send you the
> paper so that you can compare :)


I will

On Mon, 14 Aug 2006 10:55:29 +0200, Marcus Denker <[hidden email]>  
wrote:
> And have a look at BehaviorTest>>#testChange

This test is a *very* good one, 100% pure[tm] object-oriented :)

/Klaus

On Aug 14, 2006, at 11:13 AM, Klaus D. Witzel wrote:

> On Mon, 14 Aug 2006 10:55:29 +0200, Marcus Denker  
> <[hidden email]> wrote:
>> And have a look at BehaviorTest>>#testChange
>
> This test is a *very* good one, 100% pure[tm] object-oriented :)

I disagree. Whereas the _tested_ stuff is great, we don't know what  
kind of test it is, without reading it. Also - we would not find it  
easily as an example for instance specific behavior.
Certainly this is the way SUnit tests are supposed to look like, but  
who says, that SUnit is the best way (pure[tm] object-oriented) of  
testing?

I'd categorize this test as a "method test" focusing on
        Behavior >> compile: aString
(See our Unit Test Taxonomy Paper below)

I found it more object-oriented, if the test would be explicit about  
what it is showing and looked like:
===============
Behavior class (examples) >> exampleCompileThisIsATest
        "I return a sample behavior of thisIsATest ^2
        So I do not only exemplify an instance of this class, but also of  
compile: aString
        (As there is no annotation a la self test:[], an extended  
OmniBrowser could assume that it is the last method called, which is  
exemplified.)
        Browse for _real senders_ of me, to see me in context"

        |aBehavior|
        aBehavior := self new.
        aBehavior compile: 'thisIsATest  ^ 2'.
        ^aBehavior

Model class (examples) >> examplePlugInstanceBehavior
        |aModel|
        aModel := self new.
        self precondition: [self should: [aModel thisIsATest] raise:  
MessageNotUnderstood].
        aBehavior := Behavior exampleCompileThisIsATest.
        aBehavior superclass: self.
        aBehavior setFormat: self format.
        aModel primitiveChangeClassTo: aBehavior new.
        self assert: model thisIsATest = 2.
        ^aModel
===============
I think this way
- is more object oriented and you could browse the class side of  
Behavior to see how its instances can be applied
- you could reuse this instance specific behavior in more tests
- shows, that we might miss a single method to plug this instance  
specific behavior as
        aBehavior superclass: self.
        aBehavior setFormat: self format.
        aModel primitiveChangeClassTo: aBehavior new.
  is a bit verbose and could be subsumed into a single "Object >>  
changeClassTo: aBehavior" method. Thus the latter example would  
exemplify this method.

Thanks for this nice example, I think I can reuse it for academic  
purposes... ;-)

Cheers,

Markus

Please find our Test Taxonomy Paper on:
http://www.iam.unibe.ch/~scg/Archive/Papers/ 
Gael05aTowardsATaxonomyOfUnitTests.pdf

Hi Markus,

on Mon, 14 Aug 2006 12:12:07 +0200, you wrote:
> On Aug 14, 2006, at 11:13 AM, Klaus D. Witzel wrote:
> On Mon, 14 Aug 2006 10:55:29 +0200, Marcus Denker <[hidden email]>
>> wrote:
>>> And have a look at BehaviorTest>>#testChange
>>
>> This test is a *very* good one, 100% pure[tm] object-oriented :)
>
> I disagree.

I don't.

> Whereas the _tested_ stuff is great, we don't know what kind of test it  
> is, without reading it.

Why would reading a test method make it any better or worther? Perhaps you  
meant something like "understand it". That would be a quality that we  
cannot enforce on the software developer.

> Also - we would not find it easily as an example for instance specific  
> behavior.

I didn't claim that. But, because of what?

> Certainly this is the way SUnit tests are supposed to look like, but who  
> says, that SUnit is the best way (pure[tm] object-oriented) of testing?

Agreed. But also: who says that it doesn't?

> I'd categorize this test as a "method test" focusing on
> Behavior >> compile: aString

I'd have to agree if it wouldn't use #subclass: and  
#primitiveChangeClassTo:; if you remove these two we'd be in sync with  
"focus is on compile: aString testing".

> (See our Unit Test Taxonomy Paper below)

Thanks for the pointer.

Hhm[0.5*OT]: I'm not a friend of sequences of St code which begin with "  
:= self new; more: "; as soon as "self new" is over you're most likely on  
the wrong side (reuseability, extensibility, overridability).

Hhm[0.5*OT], depends. How many "browse this and that" will we tolerate  
until we'd agree on "this one is an easy to understand test or method or  
whatsoever". Seriously, what number do you suggest?

> - you could reuse this instance specific behavior in more tests

Reuse, yes! (I understand you meant potentially reused). But we should not  
discuss that "this and that has potential for being reused" unless there  
are already ~= 1 users (proof of concept exists, at least).

> - shows, that we might miss a single method to plug this instance  
> specific behavior as
> aBehavior superclass: self.
> aBehavior setFormat: self format.
> aModel primitiveChangeClassTo: aBehavior new.
>   is a bit verbose and could be subsumed into a single

Hhm, matter of taste here? I prefer verbose tests, unless there is an  
already implemented method which I can reuse (which is not the case here,  
I mean #superclass: - #setFormat: - #primitiveChangeClassTo:).

"You shall not write *new* methods just in support of tests, they are  
superflous and do by no means reflect the testee's situation." Now how  
about this?

  "Object >>
> changeClassTo: aBehavior" method. Thus the latter example would  
> exemplify this method.

Sure, no problem with your approach.

> Thanks for this nice example, I think I can reuse it for academic  
> purposes... ;-)

You are welcome :)

/Klaus

> Cheers,
>
> Markus

Hi Klaus,

On Aug 14, 2006, at 1:54 PM, Klaus D. Witzel wrote:

Yes. It is about understanding.
And I claim, that for understanding an entity you need to be able to  
read it in its context. SUnit just does not give me context of the  
tested methods and classes. So I need to read it. With SUnit I need  
to know the "how" _before_ I could understand the _what_. This is not  
so good OO i.m.h.o.

I claim that the value of examples are underestimated in OO programming.
Think of a language dictionary like Websters, where you can  
understand each word, by reading it in an exemplified use. We all  
learn by example.

>
>> Also - we would not find it easily as an example for instance  
>> specific behavior.
>
> I didn't claim that. But, because of what?

Damien asked about a paper about instance specific _behavior_.
Marcus understood that we have examples for this already built into  
Squeak, but only as a remote test case.
Maybe that was the reason why Marcus had to point him to it, and why  
Damien couldn't find this method in a context he would imagine himself.

>
>> Certainly this is the way SUnit tests are supposed to look like,  
>> but who says, that SUnit is the best way (pure[tm] object-
>> oriented) of testing?
>
> Agreed. But also: who says that it doesn't?
;-)
>
>> I'd categorize this test as a "method test" focusing on
>> Behavior >> compile: aString
>

> I'd have to agree if it wouldn't use #subclass: and  
> #primitiveChangeClassTo:; if you remove these two we'd be in sync  
> with "focus is on compile: aString testing".

Aehm, here I was fuzzy and should have said that it is actually  
exemplifying two things, at least for me:

- How to create a behavior
- How to plug it in
Interesting that you would also add the subclassing aspect, this  
would be a technical detail for me (boldly spoken, of course... too  
much traits stuff going around in our group I guess... ;-) )

Don't think so for above example. Treat examples as factories -  
actually you can find a lot of examples of examples ;-) following  
this factory aspect in Squeak. They are all commands - thus directly  
executable, which is nice. Why adding another level of indirection  
here? Why adding a parallel test class hierarchy?

But as seen below, when I have to add _lots_ of methods after the new  
to get this instance into a meaningful state, I certainly agree with  
you! But this also fits nicely with the metaphor of examples.
Having the mantra of "an example for each concept"  in mind also  
helps us in coming up with better designs -  we are already starting  
to discuss if subclassing is a concept necessary for plugging in  
behavior or if is is mere implementation issue - this discussion is  
good (though I don't have the time to pursue it...)

I'd say try to exemplify the main concepts your architecture is  
relying on - think API's. This should lead to a very high  test  
coverage and better understanding. To emphasize this claim even more,  
I'd say that in the end your acceptance tests / (checked examples of  
API's) reflecting the typical outside usage your system are enough.  
Of course we are all programmers, so we are using this low-level  
Squeak stuff, and for doing so we need to understand it. So our  
acceptance tests / examples should exists also for low level stuff.
>
>> - you could reuse this instance specific behavior in more tests
>
> Reuse, yes! (I understand you meant potentially reused). But we  
> should not discuss that "this and that has potential for being  
> reused" unless there are already ~= 1 users (proof of concept  
> exists, at least).

One advantage of viewing tests as checked examples / factories is  
above explained documentation value:
People like Damien might look into Behavior (examples) category to  
find out what is already there...

An other advantage (reuse of this technique ;-) is the _possible_  
reuse of these instances in different contexts.

Other arguments include cohesion of test and code, principle of last  
surprise (examples and tests are one of a kind (commands /  
factories), tests just come with some assertions), no parallel test  
hierarchy, ah, and no need for static typing your instance variables  
- the set of examples should include all possible concrete types  
these variables can take. (Same argument for method parameters btw.)

I'd like to have a browser, where you could fold in and out code, so  
if you liked you could see above "exampleCompileThisIsATest" inlined  
(maybe even edit it there).

>
> "You shall not write *new* methods just in support of tests, they  
> are superflous and do by no means reflect the testee's situation."  
> Now how about this?
>
>  "Object >>

no helper methods which are only used by other tests. But if these  
"helper methods" also exemplify the usage of other real methods - why  
not?
Certainly I agree that methods doing some real work always should be  
factored into the real code. Luckily we have PackageInfo for making  
clear what belongs to examples/tests and what to production code.
As been suggested in our taxonomy paper Stefan Reichert uses the  
fifth pane in Christo to display tests right to the methods they are  
calling.
He has not (yet? ;-) introduced the idea of an exemplified method,  
rather all methods called in the test now can display this test as an  
example.

Besides Stefan went a bit further in an other direction concerning  
this linkage of methods and tests, and also introduced a fifth pane  
the other way round: A test also displays all methods called by it to  
its right.

Cheers,

Markus

On Mon, 14 Aug 2006 17:47:52 +0200, Markus Gaelli wrote:
> Hi Klaus,
> On Aug 14, 2006, at 1:54 PM, Klaus D. Witzel wrote:
...
> Yes. It is about understanding.
> And I claim, that for understanding an entity you need to be able to  
> read it in its context.

This is not reality (we talk about software and its code, don't we?).  
Neither can you force the software developer to read something nor can you  
force any person to understand something. s/you/I/ and set I := Markus,  
I'd agree.

> SUnit just does not give me context of the tested methods and classes.  
> So I need to read it. With SUnit I need to know the "how" _before_ I  
> could understand the _what_. This is not so good OO i.m.h.o.

Yes, something better is needed. How about little stories on the  
whatabouts, perhaps animated. Good example:
- http://connect.larc.nasa.gov/squeak.html

> I claim that the value of examples are underestimated in OO programming.
> Think of a language dictionary like Websters, where you can understand  
> each word, by reading it in an exemplified use. We all learn by example.

You all minus: #Klaus (perhaps). I only learn when I'm able to do it by  
myself or, when I have to explain it to another person (one subsumes the  
other). Besides of that, I can only store information.

>>> Also - we would not find it easily as an example for instance specific  
>>> behavior.
>>
>> I didn't claim that. But, because of what?
>
> Damien asked about a paper about instance specific _behavior_.
> Marcus understood that...

I'm sorry this was not the question. See how hard communication is? I  
asked for the *cause* (like in: because) for your "would not find it  
easily as an example for instance specific behavior". My quesion was not  
about the people you mentioned.

Unless you're a friend of "nil subclass: #MyOwnRoot", in St you're always  
subclassing, aren't you? So this cannot be not a technical detail. It's  
like breathing.

I didn't invent the flow of control between "self new" and the immediately  
following instruction, it's intrinsic in St. And I have already added your  
understanding of the issue to my list of "natural" confusions in St ;-)

> Why adding a parallel test class hierarchy?

Because every application always runs without any test class/method being  
present in the .image?

> But as seen below, when I have to add _lots_ of methods after the new to  
> get this instance into a meaningful state, I certainly agree with you!

O.K. dropped you off of the list of software developers who *are*  
"naturally" confused by such constructs ;-)

> But this also fits nicely with the metaphor of examples.

Perhaps I'm too rigid with "... self new ... more: ..". Will think it over.

> Having the mantra of "an example for each concept"  in mind also helps  
> us in coming up with better designs -  we are already starting to  
> discuss if subclassing is a concept necessary for plugging in behavior  
> or if is is mere implementation issue - this discussion is good (though  
> I don't have the time to pursue it...)

This would be interesting to find out. There are perhaps pattern when  
subclassing is necessary and when that's not the case? Keep me up to date,  
if possible, please.

...
Have criteria for "better understanding" at hand? This is too subjective,  
IMO. "interviewer: did you understand this concept? candidate: yes!".

Whether or not something is understood can only be found out if candidate  
is using "it" after getting to known "it". This is where "to understand  
something" begins, here where I am.

> To emphasize this claim even more, I'd say that in the end your  
> acceptance tests / (checked examples of API's) reflecting the typical  
> outside usage your system are enough.

Sure.

> Of course we are all programmers, so we are using this low-level Squeak  
> stuff, and for doing so we need to understand it. So our acceptance  
> tests / examples should exists also for low level stuff.

I have never made any distinction between low and other level in software  
systems, only between provider and user of an interface. Is that what you  
mean?

If you always keep test cases and other "test supporting" methods in your  
image: yes. But that is an illusion.

> An other advantage (reuse of this technique ;-) is the _possible_ reuse  
> of these instances in different contexts.

Okay, tell me one example where a test method has been reused (not  
[re]factored!), please.

> Other arguments include cohesion of test and code, principle of last  
> surprise (examples and tests are one of a kind (commands / factories),  
> tests just come with some assertions), no parallel test hierarchy, ah,  
> and no need for static typing your instance variables - the set of  
> examples should include all possible concrete types these variables can  
> take. (Same argument for method parameters btw.)

Sure.

>> Hhm, matter of taste here? I prefer verbose tests, unless there is an  
>> already implemented method which I can reuse (which is not the case  
>> here, I mean #superclass: - #setFormat: - #primitiveChangeClassTo:).
>
> I'd like to have a browser, where you could fold in and out code, so if  
> you liked you could see above "exampleCompileThisIsATest" inlined (maybe  
> even edit it there).

+ (1 big) perhaps Stefan's Christo can be a start here?

>> "You shall not write *new* methods just in support of tests, they are  
>> superflous and do by no means reflect the testee's situation." Now how  
>> about this?
>>
>>  "Object >>
>
> no helper methods which are only used by other tests. But if these  
> "helper methods" also exemplify the usage of other real methods - why  
> not?

Because I do not pay my employees (and freelancers) for inventing test  
helper methods. It's Okay for (re)factoring test methods, but that is  
where the story ends here.

By nature of definition, all test methods are unique!

Rule of thumb: the more you have (or like) to invest into test methods,  
the less the subject (the testee) is understood.

> Certainly I agree that methods doing some real work always should be  
> factored into the real code.

Ahh, my rule of thumb at work :)

> As been suggested in our taxonomy paper Stefan Reichert uses the fifth  
> pane in Christo to display tests right to the methods they are calling.
> He has not (yet? ;-) introduced the idea of an exemplified method,  
> rather all methods called in the test now can display this test as an  
> example.
>
> Besides Stefan went a bit further in an other direction concerning this  
> linkage of methods and tests, and also introduced a fifth pane the other  
> way round: A test also displays all methods called by it to its right.

Yes, I've seen that and Stefan did a tremendous job-very good work.

/Klaus

> Cheers,
>
> Markus
>
>
>

On Aug 15, 2006, at 10:37 AM, Klaus D. Witzel wrote:

"Example isn't another way to teach. It is the only way to teach." -  
A. Einstein

Sure, creating the example yourself is more helpful than reading it  
from someone else.
But while I am redoing it or explaining it, I need it as concrete as  
possible. Maybe there are different types of personalities but think  
for example types: having the concrete types of classes and methods  
seems to be wanted in many cases - a no brainer if you had examples  
for them.

? I thought I gave an example of a not well understood concept  
(Behavior) where it would not be necessary of anybody to send an  
according test - as it is glass-clear where to find it. (Behavior  
(category examples))

So traits are like...??? ;-)

I am absolutely with you that for understanding doing is better than  
reading! But I am also saying that reading is easier and I might only  
need to read the headlines, if the headlines are linked in a  right  
context.

Yes.

Could tell you lots! See below.
>

I'd love to see this in Squeak too. Browsers should be able to  
summarize software!

Another student here, Rafael Wampfler, is building a tool for VW  
where you can do this. His tool called 'Eg' is an implementation of  
the ideas I presented.
Maybe we can meet for beer here in Bern and discuss this with a  
concrete prototype.
I keep some of my answer here, but I really think that face to face  
would be better. :-)

Indeed!

>
> /Klaus

Cheers,

Markus

Hi Markus,

on Tue, 15 Aug 2006 11:24:25 +0200, you wrote:
...
> Maybe we can meet for beer here in Bern and discuss this with a concrete  
> prototype.
> I keep some of my answer here, but I really think that face to face  
> would be better. :-)

Marcus and I have already planned for the next Smalltalk Stammtisch in  
Bern, I expect him to send out an invitation soon (he has a list of  
potential attendees).

How about Wednesday or Thursday, starting 17:30-18:00, Café Bollwerk,  
where Einstein used to relax.

/Klaus

On Tue, 15 Aug 2006 11:24:25 +0200, Markus Gaelli wrote:
> Klaus wrote:
>> Unless you're a friend of "nil subclass: #MyOwnRoot", in St you're  
>> always subclassing, aren't you? So this cannot be not a technical  
>> detail. It's like breathing.
>
> So traits are like...??? ;-)

Dead wood. They are not instantiatable and so not testable, unless you  
show me how to test traits (versus how to test one of their users ;-)

/Klaus

stéphane ducasse wrote:
> read my joop paper.

What are you referring to ? Which paper exactly please ?

go to my web page publication + alt F + JOOP Journal of Object-
Oriented Programming 1999.

Stef

On 15 août 06, at 15:22, Damien Cassou wrote:

> stéphane ducasse wrote:
>> read my joop paper.
>
> What are you referring to ? Which paper exactly please ?
>
>

http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi?query=Ducasse+JOOP+1999

On Aug 15, 2006, at 15:37, stéphane ducasse wrote:

Oscar Nierstrasz wrote:
>
> http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi?query=Ducasse+JOOP+1999

Thank you. I think I already read this paper one year ago but will read
it again.


Thanks