Subtle but incompatible change

[Brian Rice]

I forgot to illustrate this with an example:

[| :foo &bar | bar `defaultsTo: 1. foo + bar] applyTo: {3}.
4
[| :foo &bar | foo + bar] applyTo: {3} optionals: {#&bar. 4}.
7

NOTE: I have rolled back this particular interface change since it  
didn't accomplish the fix in the right way. I was too hasty with my  
analysis and didn't notice that the root of the problem is in one  
routine that was easier and more direct to fix.

So now we are back to applyTo:&optionals: and sendTo:&optionals: vs.  
applyTo:optionals:, and all of the optionals array safety checks are  
done inside the one routine in the VM that processes them.

On Feb 18, 2006, at 8:26 AM, Brian Rice wrote:

> In any case, the &optionals: keyword took an array of alternating  
> keyword symbol and value pairs, and there was not much safety in  
> this parameter-passing (which can cause crashes if used  
> incorrectly), so I extracted the feature out into an  
> #applyTo:optionals: which does contain the checking and doesn't  
> have to burden the ordinary call with verification overhead. It is  
> an exercise for the user (should they choose so) to provide a  
> better facade for that call. :)

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060218/7decb1b5/PGP.pgp