[Sc-devel] language crash

[Till Bovermann]

ok, if this is the desired behavior, go for it...

that means we should not do what hjh mentioned earlier?
june, 4th:
	"first, "or" sent to anything other than Boolean (or  
AbstractConstraint) should throw DoesNotUnderstand"

regards
Till


On 05.06.2007, at 23:50, Ryan Brown wrote:

>>> true.or("hello")
>>> // => true
>>>
>>> true.and("hello")
>>> // => hello
>
>> thanx for this... I actually don't know if we want this... it's a  
>> potential pitfall... perhaps we should check if all params of "or"  
>> and "and" are Bool?
>
> It isn't a pitfall of the patch if that's what you meant - this has  
> always been the behavior. It would not be difficult to change True  
> and False to check for the type though. This will work:
>
> True : Boolean {
> 	if { arg trueFunc, falseFunc; ^trueFunc.value }
> 	not { ^false }
> 	&& { arg that; that = that.value; if(that.isKindOf(Boolean))  
> { ^that } { this.mustBeBoolean } }
> 	|| { arg that; ^this }
> 	and { arg that; that = that.value; if(that.isKindOf(Boolean))  
> { ^that } { this.mustBeBoolean } }
> 	or { arg that; ^this }
> 	binaryValue { ^1 }
> }
>
> False : Boolean  {
> 	if { arg trueFunc, falseFunc; ^falseFunc.value }
> 	not { ^true }
> 	&& { arg that; ^this }
> 	|| { arg that; that = that.value; if(that.isKindOf(Boolean))  
> { ^that } { this.mustBeBoolean } }
> 	and { arg that; ^this }
> 	or { arg that; that = that.value; if(that.isKindOf(Boolean))  
> { ^that } { this.mustBeBoolean } }
> 	binaryValue { ^0 }
> }
>
> mustBeBoolean is already declared in Object but not used anywhere  
> for some reason (maybe James has already considered this and  
> decided against?). I'm not checking for types in "or"/"and" methods  
> that return "this" because there is code that currently depends on  
> "or"/"and" not calling a function if the first argument is enough  
> to know the result of the boolean operation (for example,  
> SequenceableCollection:insertionSortRange does this). There is  
> still a possibility that this breaks code though.
>
> I think we should just leave it as is though. Changing it will  
> likely cause many more bugs than it will fix and it will slow  
> things down very slightly (isKindOf is a fast numerical operation).  
> The current behavior is the same as smalltalks, and was actually  
> discussed for squeak here: http://wiki.squeak.org/squeak/261
>
> Ryan
>
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel at create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel