Problem with update 5947 changes to SimpleServiceEntry and BFAV2

Doug Way dway at
Tue Jun 8 22:38:15 UTC 2004

Actually, I sort of anticipated this when I approved Ned's changes, see:

In any case, Ned posted a set of changes for BFAV in his original post, 
which I *think* should solve the problem, although I haven't tried them:

(of course we may have to merge those with the numerous BFAV changes 
which are on SqueakSource and haven't been released yet...)

- Doug

Ken Causey wrote:

>Well, today's harvesting party is a bust due to an incompatibility
>between BFAV2 and update 5947.
>In update 5947 Ned provided some FileList* related changes including
>changing the usage of SimpleServiceEntry.  Pre-5947 SimpleServiceEntry
>assumed that you passed it the list of arguments for the service when
>calling SimpleServiceEntry>>performServiceFor: or
>SimpleServiceEntry>>performExtraFor: and friends.  Admittedly this
>resulted in some rather strange looking code like 
>performAttachmentService: aServiceEntry on: anAttachment
>	aServiceEntry perform: aServiceEntry requestSelector
>		withArguments: { aServiceEntry getArgumentsFrom: 
>							(PatchArchiveAttachment fullName: anAttachment) }.
>With 5947 Ned changed performServiceFor: so that it assumes that is is
>supposed to extract the arguments with getArgumentsFrom:.  The more I
>think about it the more this seems like the correct thing to do. 
>However I will note that performExtraFor: has not been updated to follow
>this convention.
>I guess my suggestion for now is that BFAV2 be updated to take this new
>model into consideration.  Here's a small changeset against 5.09...
>uh, hmm...
>Looks like it's not going to be that easy.  5947 changes things all over
>the place.  The services don't seem to standardize on wanting the just
>the filename anymore...  Namely, FileContentsBrowser
>class>>serviceBrowserCompressedCode expects something closer to a
>FileList than what the facade PatchArchiveAttachment provides.  It's
>just a bit funny that this facade was provides for BFAV by Ned. ;)

More information about the Squeak-dev mailing list