Shorter still:
switch (the platform)
case “MacOS” ; put Finder into tReference ; break
case “Win32” ; put Explorer into tReference ; break
default ; put Desktop into tReference
end switch
You don’t need a break after default. :-)
Bob S
On Jan 22, 2015, at 24:08 , René
Thank you Bob !
:-)
René
Le 23 janv. 2015 à 23:22, Bob Sneidar bobsnei...@iotecdigital.com a écrit :
Shorter still:
switch (the platform)
case “MacOS” ; put Finder into tReference ; break
case “Win32” ; put Explorer into tReference ; break
default ; put Desktop into
Le 21 janv. 2015 à 18:54, Ken Ray k...@sonsothunder.com a écrit :
easier/shorter then:
switch (the platform)
case MacOS
put Finder into tReference
break
case Win32
put Explorer into tReference
break
default
On Jan 21, 2015, at 9:54 AM, Ken Ray k...@sonsothunder.com wrote:
I use a similar inline switch:
put stsSwitch(the platform,MacOS=Finder,Win32=Explorer,*=Desktop)
into tReference
One line can accomplish that even without invoking a custom function:
put item itemOffset( the platform,
On Thu, Jan 22, 2015 at 1:42 PM, Ben Rubinstein benr...@cogapp.com wrote:
Sorry, I've only just realised as I was about to press send that the point
you were making was that if it was built-in, then it also wouldn't need to
evaluate both outcomes. Good point - though I'd personally still tend
On 21/01/2015 15:53, Geoff Canyon wrote:
the obvious drawback of the way it is now is that both outcomes have
to be evaluated, where in an if statement, obviously, only one of them is.
True, but (coding style preference) I tend to use it pretty much only for
constants. If there's a complex
I was thinking of doing a switch version, so thanks!
On Wed, Jan 21, 2015 at 11:54 AM, Ken Ray k...@sonsothunder.com wrote:
local baseID
function baseID newID
put iff(validID(newID),newID, \
iff(validID(baseID), baseID,this card)) into baseID
return baseID
end baseID3
local baseID
function baseID newID
put iff(validID(newID),newID, \
iff(validID(baseID), baseID,this card)) into baseID
return baseID
end baseID3
Of course you could reduce it one step further:
function baseID newID
return iff(validID(newID),newID, \
I believe dBase/Foxpro had an iif function. That is because they also had an if
control structure command and the compiler needed to discern between the two.
Bob S
On Jan 21, 2015, at 07:15 , Ben Rubinstein benr...@cogapp.com wrote:
On 21/01/2015 01:58, J. Landman Gay wrote:
On 1/20/2015
I know iff means in-and-only-if, but I have a habit of taking things that
are not functions and making them into functions by appending an f so I
went with it.
I agree that it would be a very useful thing to have -- the obvious
drawback of the way it is now is that both outcomes have to be
On 21/01/2015 01:58, J. Landman Gay wrote:
On 1/20/2015 7:33 PM, Geoff Canyon wrote:
The nested if statements in the first
one, and the duplicated
set the baseID of this stack to this card
offend my eye.
There's two of us then.
Me three.
Also I was glad to see you also have a reflex
A slightly corrected/modified version.
To set the baseID:
set the baseID of this stack to baseID(newID)
To get the baseID
get the baseID of this stack.
The function(s) then become
function baseID newID
if newID is empty then
return baseID_newIDempty()
else
return
I'd go with the first one. The second one makes my eyes glaze over! Plus I
think there should be an else before the second if in the second function.
I might consider something like this.
function baseID newID
if newID is empty then
baseID_newIDempty
else
baseID_newIDnotempty
It would be good to post code that works:
function baseID newID
if (newID is not empty and not exists(newID)) or \
(newID is empty and not exists(the baseID of this stack)) then \
set the baseID of this stack to this card
if newID is not empty then set the baseID of this
The first is slightly faster, but they don't return the same result -
running the code below I always get:
6 8 false
this card 1000
Did I mess up the test somewhere?
on mouseUp
put 1000 into tIterations
--
set the baseID of this stack to empty
put the millisecs into t
repeat
okay, I think this is correct for both versions (gah)
function baseID newID
if newID is empty then
if not exists (the baseID of this stack) then
set the baseID of this stack to this card
end if
else
if exists(newID) or \
newID is among the items of
Thanks for the fix. Once I took care of the email line wrap it ran
well. The first version is still slightly faster, and to my eye more
readable, so I'd go with that.
on mouseUp
put 1000 into tIterations
--
set the baseID of this stack to empty
put the millisecs into t
I figured the first version would be faster, since it only checks each
thing once, where the second version tests some booleans twice, but this
isn't going to be called repeatedly, so maximum performance isn't an issue.
I was more curious about the readability, because I thought I might be the
On 1/20/2015 7:33 PM, Geoff Canyon wrote:
I was more curious about the readability, because I thought I might be the
odd one out here, and it seems I am. The nested if statements in the first
one, and the duplicated
set the baseID of this stack to this card
offend my eye.
There's two of
19 matches
Mail list logo
