[Sc-devel] language crash

[Till Bovermann]

is this checked in to the svn already?
If not we should do this asap...


regards
Till

On 06.06.2007, at 19:36, Ryan Brown wrote:

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