Thank you Bob !
:-)
René
> Le 23 janv. 2015 à 23:22, Bob Sneidar 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 tReference
> en
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 ,
On Thu, Jan 22, 2015 at 1:42 PM, Ben Rubinstein 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 to
> restrict t
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
> On Jan 21, 2015, at 9:54 AM, Ken Ray 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, "MacOS,
> Le 21 janv. 2015 à 18:54, Ken Ray a écrit :
>
> easier/shorter then:
>
>switch (the platform)
>case "MacOS"
>put "Finder" into tReference
>break
>case "Win32"
>put "Explorer" into tReference
>break
>default
>
I was thinking of doing a switch version, so thanks!
On Wed, Jan 21, 2015 at 11:54 AM, Ken Ray wrote:
> > local baseID
> >
> > function baseID newID
> > put iff(validID(newID),newID, \
> > iff(validID(baseID), baseID,"this card")) into baseID
> > return baseID
> > end baseID3
>
> Of
> 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, \
iff(vali
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 evalu
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 wrote:
>
> On 21/01/2015 01:58, J. Landman Gay wrote:
>> On 1/20/2015 7:33 PM, Geof
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 refle
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 o
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
odd
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
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 "t
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 tI
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 baseID_newI
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
19 matches
Mail list logo
