Default package and SUnit

So, I finally got around to doing some testing again, and brought over a
bunch of code from other dialects. The default package concept
functioned just the way I wanted during file-in. Afterwards, though, I
brought over some methods (on existing classes) via cut-and-paste,
having changed the default package in the mean time, and wondered why
the methods didn't show up in the same package as the classes they were
defined in did. I finally realized that the default package behavior was
still working (quite aggressively). That's a bit more than my spec said,
I guess. The default package is mainly meant for file-in. Any way, it
now works like a change set, and I guess I can live with that. Guess I
just don't like surprises ;-)

I've attached a package with some useful extensions to SUnit that I've
been using. Feel free to try them out. They require two changes to the
current SUnit implementation - changes which will be in the next SUnit
update anyway. If you want to try the package out, file in <grin> these
two methods first:

!TestResult methodsFor!

failures
        failures isNil ifTrue: [failures := Set new].
        ^failures! !
!TestResult categoriesFor: #failures!Accessing!public! !

!TestResult methodsFor!

defects
        ^self errors addAll: self failures; yourself! !
!TestResult categoriesFor: #defects!Accessing!public! !

>From the package comment:

SUnit Extensions add some useful extensions like #assert: with a
description, and resumable TestFailures. It currently overrides two
methods in TestResult which will be changed in the next SUnit core
release.

The main method of interest is TestCase>>#assert:description:. This
takes a String as second argument. Normally, if the test case fails,
this string will be written to the Transcript. Of course, this string
can be constructed dynamically.

 | e |
 e := 42.
 self assert: e = 23 description: 'expected 23, got ' e printString

You can choose whether to log by overriding #isLogging, and choose where
to log to by overriding #failureLog. This package also provides a number
of syntactically sugary extensions to this method.

The second add-on is the resumable TestFailure. Why would you need this?
Take a look at this example:

 aCollection do: [ :each | self assert: each isFoo]

In this case, as soon as the first element of the collection isn't Foo,
the test stops. In most cases, however, we would like to continue, and
see both haw many elements and which elements aren't Foo. It would also
be nice to log this information. You can do this in this way:

 aCollection do: [ :each |
  self
   assert: each isFoo
   description: each printString, 'is not Foo'
   resumable: true]

This will print out a message on the Transcript for each element that
fails. It doesn't cumulate failures, i.e., if the assertion fail 10
times in your test method, you'll still only see one failure.

Enjoy!
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
Krysten Nygaard

"Joseph Pelrine" <[hidden email]> wrote in
message news:[hidden email]...
Joseph, I am quite dismayed by this. I explicitly asked you the question:
"Would you propose that all new definitions (classes, methods, resources,
etc) be added to the default package even when defining things in browsers?"

And you answered: "Yes!". I am at a loss as to how we managed to
misunderstand each other :-(.

You also said that the default package was "very convenient, especially if
you are filing code in". Not: "but only if you are filing code in". I also
expressed my concern that establishing such a 'mode' would result in
unpleasant "surprises", just like the one you had.

Anyway, regardless of misunderstandings on either side, what precisely do
you (and others) think the default package should do. I will outline here
what it currently does:

1) When set the default package will assimilate all *new* class and method
definitions. This also includes, at present, those methods which result from
rename refactorings, which is, ahem, undesirable.
2) *Updated* methods and classes are unaffected, regardless of whether they
come from a file-in or not. So if one files in some code only the newly
defined methods and classes will hit the default package, the updated
methods will be taken to be updates to the packages of the pre-existing
methods. We exchanged some e-mail specifically on the question of how
updated methods should be handled, and I recall that leaving things where
they were was the behaviour you suggested.
3) The dialog for adding new classes has explicit means for specifying the
package, which will override the default package unless one ticks off the
'Packaged?' check box (which is a little confusing, I know). If no default
package is set and the tick box is off, then the class will be
unpackaged/uncommited. With the default package set it will end up in there.

I can't help thinking this 'mode' is actually rather a bad idea, and that it
would make far more sense to have a 'File-in to Package' command that
allowed one to perform a file-in within the context of a package, thereby
capturing all new *and* updated methods. Within the browsers I don't think
there is any need (at least not now) for a 'Default Package', because one
can define new classes directly into an explicitly chosen package right now,
and new methods in the context of a package in the System Browser (or we
could easily arrange for that to be so, for example by prompting for the
class of new methods one saves with a single package selected and no class
selection, and/or by having an explicit 'Accept into Package' command).

Frankly I think it is too late to change this now, but it would be nice to
know what people would like to see in future. It also might just get done
because there are two gentlemen here that feel very uncomfortable every time
something even slightly resembling a mode is suggested :-).

Regards

Blair

P.S. The changes to the SUnit base you kindly sent me have been applied and
will be in the release.

Hi Blair and Joseph,

> would make far more sense to have a 'File-in to Package' command that
> allowed one to perform a file-in within the context of a package, thereby
> capturing all new *and* updated methods.

This gets my vote. I dont think I would use the default package in any other
circumstances, and it definitely would help to identify updated methods
after a file-in.

Thanks,
Steve

Steve Waring wrote:

> Hi Blair and Joseph,
>
> > would make far more sense to have a 'File-in to Package' command that
> > allowed one to perform a file-in within the context of a package, thereby
> > capturing all new *and* updated methods.
>
> This gets my vote. I dont think I would use the default package in any other
> circumstances, and it definitely would help to identify updated methods
> after a file-in.

I agree with Steve. Blair, I'm extremely sorry that we had a misunderstanding -
it surely wasn't my intention. As I mentioned in my first post, I can live with
either implementation, as long as I know what it does. I'll buy you a beer or
three next week, and we can look at what happened. OK?

Also, thanks a lot for rolling in the SUnit changes. With them, Dolphin is
leading the pack!


--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
Krysten Nygaard

"Joseph Pelrine" <[hidden email]> wrote in
message news:[hidden email]...
> Steve Waring wrote:
>
> > Hi Blair and Joseph,
> >
> > > would make far more sense to have a 'File-in to Package' command that
> > > allowed one to perform a file-in within the context of a package,
thereby
> > > capturing all new *and* updated methods.
> >
> > This gets my vote. I dont think I would use the default package in any
other
> > circumstances, and it definitely would help to identify updated methods
> > after a file-in.
>
> I agree with Steve. Blair, I'm extremely sorry that we had a
misunderstanding -
> it surely wasn't my intention.

Don't worry, I'm over it now :-).

>...As I mentioned in my first post, I can live with
> either implementation, as long as I know what it does.

Ok, so the preferred solution (at least on the basis of three votes, that's
me, your and Steve) is to drop the default package mode, and instead have a
'File In' command that operates within the context of a package, and
assimilates everything defined by the file-in, new or existing. Is that
right? I'll assume so if no-one complains. This could be achieved by adding
a 'File Into...' command to the the package context menus in the package
browser and system browser's. I think we'll have to live with the default
package in this release though, there is still too much else to do.

>...I'll buy you a beer or
> three next week, and we can look at what happened. OK?

Careful, I might bring my drinking trousers, and if I don't Andy will
certainly be in his (he wears them all the time).

>
> Also, thanks a lot for rolling in the SUnit changes. With them, Dolphin is
> leading the pack!

No problem.

Regards

Blair

Blair McGlashan wrote:

> [snip]

You don't have to totally remove it, you know. You could sell it as a "VW/Squeak
changeset compatibility mode" ;-) I think the 'File Into Package' option is more
elegant, though.

>
>
> >...I'll buy you a beer or
> > three next week, and we can look at what happened. OK?
>
> Careful, I might bring my drinking trousers, and if I don't Andy will
> certainly be in his (he wears them all the time).

Well, it can't get much worse than the last Smalltalk Solutions!

--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"Inheritance was invented at 2 AM between January 5th and 6th, 1967" -
Krysten Nygaard