About Smalltalk at: .... ifAbsent:/present:

stéphane ducasse ducasse at iam.unibe.ch
Tue Nov 30 11:13:50 UTC 2004


Hi andreas

I'm mnore precise on my thoughts now after discussing mwith marcus and 
alex...I would like to identify what is class based responsibility vs. 
what is package-based responsibility. So in this quest I see severla 
cases:

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.

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.

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).

In the context of the Smalltalk at:#MD5 ifPresent:...
registration mechanism is overkill.

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. 
I have the impression that this is a question of size.

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

I do not know but I would like to understand the architecture and 
properties that packages would bring to us.

Stef



> Hi Stef -
>
>> It seems that:
>> - first it would be better to let the compiler compiles method with 
>> reference to classes that are not in the system and let the system 
>> complain at execution tim (marcus suggestion and he can explain that 
>> much better than me).
>
> I doubt this. Yes, all of these could be re-written as, say:
>
>    Foo ifNil:[self mumble].
>    Foo ifNotNil:[Foo bar].
>
> instead of
>
>    Smalltalk at: #Foo ifAbsent:[self mumble]
>    Smalltalk at: #Foo ifPresent:[:foo| foo bar].
>
> but the main point is that the latter two are very verbose in 
> conveying the intention that "yes, the caller is very well aware that 
> Foo may be absent and that the dependency is a weak one". If you know 
> how to read to the first one the same may be true but the latter is 
> just simply obvious in this regard.
>
>> - second, it occurred to us that packages are missing in some cases 
>> because having a dependency mechanism
>> (I'm not sure that it is the solution) would make sure that the code 
>> needing to be invoked is present in the image by the structural 
>> dependency between packages or registration where optional code can 
>> be declared
>
> I don't understand that. The whole point of using "Smalltalk at: #Foo 
> ifAbsent:[]" is to declare a weak dependency, e.g., the presence of 
> Foo may be advantageous but is by no means required. Of course, a 
> dependency system could model these weak dependencies as well but only 
> at the cost of clarity (see above).
>
>> We would really appreciate to get you open a browser, look at the 
>> code (clean if you identify some dead code, ugly methods ;)) and 
>> share with us your impressions. And what are the solutions you see, 
>> because it seems to us that there are far too much use of this idiom.
>
> I'm not at all convinced that this is a bad idiom. The only problem I 
> have with it is that it doesn't come up when you browse the references 
> to a class (but that problem is easily fixable if someone just cares 
> enough) and while you have made some points on how to "fix" the idiom 
> you haven't made a very good (or bad ;-) argument why to fix it to 
> begin with, e.g., why you'd think this idiom is problematic.
>
> Cheers,
>  - Andreas
>
>




More information about the Squeak-dev mailing list