Hi Stef -

> 1- you have a strong dependency between your classes: ie A to work need B 
> and this could be solved
> by dependencies between package (PA will work only if PB will be in). So 
> we can push to the package the responsibility and avoid ifPresent at the 
> code level.

Yes. I think that the idiom should not be used with strong dependencies (and 
I don't think I've ever seen it used in this case).

> 2- you want to express optionla behavior: for example
> if you look at clientEmail (I do not remember) but you can Smalltalk at: 
> #MD5 ifPresent: [do Z]
>
> what the code is doing is:
> in case of MD5 been present then do something extra
> else do not care.

Yes. Or alternatively choose different algorithms such as 
Form>>displayInterpolatedOn: which tries to use B3D for drawing and falls 
back onto WarpBlt if B3D is not present.

> Now this means that this is one way to express registration (a bit similar 
> to the file list
> the file will do something only if certain tool are loaded and this is not 
> the file list responsibility to say if this guys is in I will do that 
> since it does not know which guy can be there).

No. This is very different. In the FileList example, FileList does 
absolutely nothing by itself it is just a registry for a set of actions 
which need to be matched to files. Whereas here we have a very specific 
action to be performed, with the optional support of some other package.

> Then the next question is: is it the responsibility of the EmailClient to 
> check whether MD5 is there or is it the responsibility of MD5 to
> say I'm here to potential client.

It's both - and indeed this is precisely what happens. The MD5 package 
announces its presence by registering the classes in the environment 
(Smalltalk or otherwise) and the client checks if the MD5 is present and 
functioning.

> The next question is if we have package do we want to move that at the 
> package level vs class
> PackageRegistry if: #MD5 do: []. ?

This can be useful in situations where classes aren't the primary entry 
point but rather method interfaces. I think this would be a useful addition 
to the class-based tests.

Cheers,
  - Andreas