Add Switch to Xojo language

General
1

I find myself using Select Case always. I converged “If Then” and “Select Case” into one. The main reason being; “Then” and Object focus.
It would be nice to have (in time) replace both (IfThen and SelectCase) by a “Switch” construction. Something like:
Switch(expression)
Case x
// code block
Case y
// code block
Else
// code block
End Switch

1 Like
2

How is that different? Select case is very flexible already.

1 Like
3

:face_with_raised_eyebrow: is not the exact same thing???

Select Case Expression
Case x
 'Code
Case y
 'Code
Else
 'Code
End Select
4

There MIGHT be a discussion IF you expect more than one code block to be run, or if you want to choose which of the cases runs first

eg

Var thing as integer = 4

select case thing
case 1..5
//code block    .. 4 qualifies here
case 3..6
//code block     .. 4 qualifies here also
case else
//if no case qualified
end select

With Select case, the first code block runs, and no other.
Most (All?) Switch…Case constructs work the same way.

Maybe the OP wants 2 code blocks to run?

5

Fundamentally, there is no difference. It is compacter and more in line with the new languages like JavaScript and Python. As young, new Xojo users will be used to.

6

Explain how it is more compact. Actually the switch in JS is less compact, as you need a break; at the end of each case to prevent falling into the one below.

4 Likes
7

Xojo needs a lot more to modernize the language than the ability to fire multiple clauses of a select statement. And that’s even if it’s something we want. I don’t really. The versions that need break statements always felt… bloated. And since we use break for a breakpoint, what would we even call the stop statement?

I’d much rather see closures, promises, and async/await.

5 Likes
8

if they were to do it “Exit” comes to mind

As a 20+ year RB/RS/Xojo user I am not sure exactly sure what all those things are, but there have been very view if any (besides maybe Var) changes to the language vs the framework (what as the last?) for a LONG TIME, so I don’t think it’s likely.

That is unfortunate as i would have liked Xojo to stay more current i terms of basic capabilities to help expand it’s capabilities and my knowledge and capabilities as a coder.

I may not be a “Pro” but I like learning new concepts…

When I first started with RS, OOP was new to me coming for old school BASIC, FORTRAN, Pascal, and several other languages (like one 8 bit based on ALGOL and a few 4GLs on minicomputers )…

The world has changed in the last 20+ years and so have the capabilities of programming languages …

Xojo needs to do more than (IMO mostly pointless) rename things to stay relevant IMO!..

But that does not mean becoming C like!

-Karen

3 Likes
9

No. In C all cases gets tested and execute if true. In Xojo testing stops when a case is true.

In C to get the Xojo behavior you have to put “break” at the end of of the case to precent the other cases from being tested and tested. Break exits the construct immediately.

-Karen

2 Likes
10

They are modern tools that make asynchronous logic easier. For example in JavaScript, an HTTP request could be done with:

function lookupSomething(thing) {
	fetch(`https://website.domain/api/v1/something/${thing}`).then((response) => {
		alert(`Here is the response to ${thing}`);
	}).catch((err) => {
		alert('Here is the error');
	});
	alert('This happens while the fetch is running');
}

What’s happening here is the fetch gets silently spun off into another thread. The alert after the fetch fires immediately, because the code is not waiting for the fetch to complete. The then is a closure - an anonymous function - that gets fired when the fetch completes. Notice it still has access to the thing variable.

If you wanted to write the same thing more linearly, this is where async/await comes in. Instead, we declare the entire function as asynchronous and we can wait for the fetch to complete:

async function lookupSomething(thing) {
	try {
		const response = await fetch(`https://website.domain/api/v1/something/${thing}`);
		alert('This happens after the fetch has completed');
	} catch (err) {
		alert('This is the error handler');
	}
}

In either case, in something like a button handler, we call lookupSomething('whatever') and it’ll asynchronously do the work. No need to explicitly setup thread instances, variable sharing, subclasses, or all the verbose options we have today.

Python - and I’m confident others I’m less familiar with - have pretty much the same thing.

I’m not saying it wouldn’t be a major language investment. But it would definitely lower the barrier to entry for asynchronous usage. Right now making a simple HTTP request is tedious no matter how you approach it.

3 Likes
11

I was thinking along the same lines here. Those JavaScript bits are essentially anonymous functions without parameters. Anonymous functions would be pretty useful in Xojo in a variety of contexts.

2 Likes
12

I don’t know much about writing plugins for Xojo - can a plugin introduce entirely novel syntactic structures, like a Switch statement?

13

No

1 Like
14

xojo could add alias names for keywords, method names, or a makro replacement.

somehow
Select Case Alias Switch
End Select Alias End Switch
it would help converting source code from other languages to xojo.

There MIGHT be a discussion IF you expect more than one code block to be run

i would use

Select Case a
Case 1,2
  MethodX
  MethodY
Case 3
  MethodY
End Select

to have a better overview of the conditions, longer code blocks should be a method.

15

Thanks for the explanation Thom.

-Karen

16

Aliases is something that I’ve been asking for. It is really nice to have them in the alternative tool that I am learning.

2 Likes
17

Now i want those features badly haha

2 Likes