Detect a Dimmension object without .typename

remus

There goes that cunning plan then.

tbd

on a 100 lines each with a dimension

0.003


Sketchup.active_model.entities.reject {|x| x.class==Sketchup;;Drawingelement}

0.007 - 0.014


Sketchup.active_model.entities.reject {|x| x.typename=="DimensionLinear"}

AlexMozg

Сompromise decision, at the proper time to use both methods:


class Sketchup;;Entity
   def is_a_type?(t)
      t.is_a?(String) ? (self.typename == t) ; self.is_a?(t)
   end
end

Multiplying speed in ~1.5-2 times

thomthom

@unknownuser said:

on a 100 lines each with a dimension

0.003


> Sketchup.active_model.entities.reject {|x| x.class==Sketchup;;Drawingelement}
>

0.007 - 0.014


> Sketchup.active_model.entities.reject {|x| x.typename=="DimensionLinear"}
>

Problem is, DimensionRadial is also a Sketchup::Drawingelement.

What I'm doing now is do a entity.kind_of?(Sketchup::Drawingelement) && entity.typename == "DimensionLinear"
That way the slow type checking is only used when there's a potential it's a dimension object.

AdamB

..and you know for certain Ruby evaluates left to right?

thomthom

@adamb said:

..and you know for certain Ruby evaluates left to right?

erhh..? no... I just assumed it did. ..it doesn't?

thomthom

I actually thought all scripting/programming languages evaluated left to right. That short-circut logic as a fundamental design.

tbd

it evaluates left side, then right side and then the operation between.

here is an example:


1==1 && (p "me too";true)
=> true

so in your example you will not see any speed improvement

thomthom

I didn't understand that example. But I did a test:


def always_return_false
	puts 'call always_return_false'
	return false
end

def always_return_true
	puts 'call always_return_true'
	return true
end


def test1
	if always_return_false && always_return_false
		#...
	end
end

def test2
	if always_return_true && always_return_true
		#...
	end
end

When I run the code:


>> test1
call always_return_false
nil
>> test2
call always_return_true
call always_return_true
nil

In the first case when the first check returns false it doesn't trigger the second check. I can't understand anything else than .kind_of? would do the same.

tbd

my mistake, i was wrong. if left side is false the right side doesn't get evaluated

Jim

@unknownuser said:

if left side is false the right side doesn't get evaluated

This is my understanding also, but watch because the and operator is not the same as &&. I don't think and will shortcut.

thomthom

@jim said:

but watch because the and operator is not the same as &&. I don't think and will shortcut.

I did two more tests for this:


def test3
	if always_return_false and always_return_false
		#...
	end
end

def test4
	if always_return_true and always_return_true
		#...
	end
end

Results:


>> test3
call always_return_false
nil
>> test4
call always_return_true
call always_return_true
nil

thomthom

Found what the difference between and and && is:

@unknownuser said:

The binary "and" operator will return the logical conjunction of its two operands. It is the same as "&&" but with a lower precedence

AdamB

@thomthom said:

Found what the difference between and and && is:

@unknownuser said:

The binary "and" operator will return the logical conjunction of its two operands. It is the same as "&&" but with a lower precedence

Well that explains something that I've been bitten by a few times..

mask = mask or object.getmask

assigns mask to itself and ors with the results of object.getmask()!!

I end up having to do:

mask = (mask or object.getmask)

What kind of madman would introduce such an operator?

Actually the one that beats all for sheer insanity is ruby.h #define-ing fopen() to be something completely different calling some Ruby thing. What the!, Argggh...

I've got some harsh language for Mr.Ruby when/if I meet him.

Adam

thomthom

I think I've always used && and || so I've avoided such problems. But I have had unexpected behaviour when I used not instead of !. I used not some times simply because I thought it was the same thing - but not would read better.

Looking at the table of Operator Precedence I can see how it all fits together now. http://www.techotopia.com/index.php/Ruby_Operator_Precedence

AdamB

Sure, it lists them out.

But I see absolutely no compelling reason to have "Logical AND" differing from "Logical composition" wrt precedence.

What is the 'use case' for the 2 forms? Does anyone know?

Adam

tbd

@adamb said:

What is the 'use case' for the 2 forms? Does anyone know?

maybe to play jokes like this :


myvar = true and false
=> false
myvar
=> true

RickW

@adamb said:

I end up having to do:

mask = (mask or object.getmask)

But now you know you can use

mask = mask || object.getmask

It saves typing the parentheses... (FWIW)

thomthom

Saves you typing even more if you type mask ||= object.getmask