[Sc-devel] language crash

[Ryan Brown]

That was fixed with the original C patch:

"hello".or
// => DNE

"hello".and
// => DNE

1.or
// => DNE

0.or
// => DNE

c = IsEven.new.or(IsIn([3, 5]))

c.value(5)
// => true

c.value(6)
// => true

c.value(7)
// => false

Ryan

On Jun 6, 2007, at 2:15 AM, Till Bovermann wrote:

> 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
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel at create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>