I was surprised

This has been this way for aeons, but it surprised me:

false | 'hello'  ==> 'hello'

Does anything actually depend on this being this way?

Or by people making a mistake

'a' = 'a' | 'a' = 'b' ==> false

On Tue, Jan 3, 2017 at 1:17 PM, Bob Arning <[hidden email]> wrote:

This has been this way for aeons, but it surprised me:

false | 'hello'  ==> 'hello'

Does anything actually depend on this being this way?

Unlikely. It's only ever used with booleans.

- Bert - 

If you use #or: instead of #| (which should always be the case IMO,
because you hardly ever want non-short-circuit boolean evaluation), then
you'll probably not forget the parentheses:

  'a' = 'a' or: [ 'a' = 'b' ] "==> true"

Or even if you do forget them, you'll still get the expected result
because of the higher precedence:

  'a' = 'a' or: 'a' = 'b' "==> true"

Levente

On Tue, 3 Jan 2017, Bob Arning wrote:

Hi Bob,

It is the same in VA Smalltalk.  The code of false>>| is:

| aBoolean

        "Answer true if either the receiver or aBoolean
         is true; answer false otherwise."

        ^aBoolean

This is about as simple an implementation as one can have.  Anything else would require testing
the class of the parameter (aBoolean) adding a fair amount of overhead for what I think is very
little gain.  I expect the error would be found soon anyway when the result is sent an #ifTrue:
like message.

Lou

On Tue, 3 Jan 2017 07:17:45 -0500, Bob Arning <[hidden email]> wrote:

>This has been this way for aeons, but it surprised me:
>
>false | 'hello'  ==> 'hello'
>
>Does anything actually depend on this being this way?
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon

I rarely use | myself, but I was translating some javascript and trying not to misread it and failed to think about the parens in that case. When the code was not working correctly, I was scratching my head until I saw my mistake, but my surprise was that it hadn't blown up the first time I ran it.

If you use #or: instead of #| (which should always be the case IMO, because you hardly ever want non-short-circuit boolean evaluation), then you'll probably not forget the parentheses:

    'a' = 'a' or: [ 'a' = 'b' ] "==> true"

Or even if you do forget them, you'll still get the expected result
because of the higher precedence:

    'a' = 'a' or: 'a' = 'b' "==> true"

Levente

On Tue, 3 Jan 2017, Bob Arning wrote:

Or by people making a mistake

'a' = 'a' | 'a' = 'b' ==> false


On 1/3/17 10:06 AM, Bert Freudenberg wrote:
      On Tue, Jan 3, 2017 at 1:17 PM, Bob Arning [hidden email] wrote:

            This has been this way for aeons, but it surprised me:

            false | 'hello'  ==> 'hello'

            Does anything actually depend on this being this way?

Unlikely. It's only ever used with booleans.

- Bert - 

You would find the error in that case, but

'a' = 'a' | 'a' = 'b' ifTrue: []

runs runs without error, although probably not the way the author intended. Just for fun I have modified my image to insist the arg be a boolean. Nothing unexpected so far.

Hi Bob,

It is the same in VA Smalltalk.  The code of false>>| is:

| aBoolean

	"Answer true if either the receiver or aBoolean
	 is true; answer false otherwise."

	^aBoolean

This is about as simple an implementation as one can have.  Anything else would require testing
the class of the parameter (aBoolean) adding a fair amount of overhead for what I think is very
little gain.  I expect the error would be found soon anyway when the result is sent an #ifTrue:
like message.

Lou

On Tue, 3 Jan 2017 07:17:45 -0500, Bob Arning [hidden email] wrote:

This has been this way for aeons, but it surprised me:

false | 'hello'  ==> 'hello'

Does anything actually depend on this being this way?