Android Question [B4X] Optional sub parameters

This feature is the icing on the cake. technically speaking, optional sub‑parameters are syntactic sugar. it makes the code look much cleaner and improves readability

Make sure to read: [B4X] Optional sub parameters

It helps design and provide cleaner APIs. It allows setting good defaults, without restricting the developer.

Take File.OpenOutput for example. Last parameter is the append flag. There are very few cases where this flag is set to True, so why force the developer to enter it each time.
It is also a much nicer alternative to multiple versions of the same method (DoSomething, DoSomething2(WithParameter)...).

Last but not least, in some cases it allows changing the API without breaking existing code.

Imagine I have a sub for inserting or updating a row in database table.
In the pass, I need to use Array, Map, custom type to create a cleaner sub with single parameter or leave empty Strings when call it. It looks ugly and may need more lines of code.
Now

I think it is also useful for initializing values when create custom type.

Thanks for the explanation, as I get older I find it harder to grasp new things, so has chatgpt explain it to me like a kindergartener, so here's what I got


Understanding the New B4X Optional Sub Parameters—with Practical Examples

B4X is introducing support for optional Sub parameters. This feature allows us to declare parameters with default values so callers do not have to supply every parameter every time a Sub is called.

In simple terms, an optional parameter tells the compiler:


This can make our code shorter, easier to read, easier to maintain, and much easier to extend without breaking existing calls.

The original announcement can be found here:

https://www.b4x.com/android/forum/threads/b4x-optional-sub-parameters.171906/'][B4X] Optional Sub Parameters[/URL]

1. A simple example

Consider the following Sub:


Every time we call it, all three parameters must be provided:


This is fine, but imagine that most messages use the same title and duration. We would repeatedly pass the same values throughout the application.

With optional parameters, the Sub can be declared like this:


Now it can be called with only the required parameter:


The compiler effectively treats this as:


We can override only the title:


The default duration of 2000 will still be used.

We can also override everything:


The common call remains short, while unusual cases can still be fully customized.

2. Optional parameter syntax

A parameter becomes optional when a default value is assigned to it in the Sub declaration:


It can then be called in several ways:


These calls mean:


There is no separate Optional keyword. Assigning a default value with = is what makes the parameter optional.

3. Optional parameters must come last

All required parameters must appear before the optional parameters.

This is valid:


In this example:

• 
  []Command is required.
  []Timeout is optional.
• RetryCount is optional.

The following declaration would not be valid:


The problem is that DeviceId is required but appears after an optional parameter.

The basic rule is:


Once a parameter has a default value, all parameters following it must also have default values.

4. Omitting trailing parameters

Suppose we define:


We can use the following calls:


Each call supplies parameters from left to right.

What we currently cannot do is skip a parameter in the middle:


That imaginary call would mean:

• 
  []Use the default timeout.
  []Use the default retry count.
• Set WriteLog to False.

According to the announcement discussion, skipping middle parameters is not currently supported.

Optional parameters can therefore be omitted only from the end of the argument list.

This is important when designing a Sub. Parameters that callers will frequently override should generally appear before parameters that will rarely be changed.

For example, if WriteLog is changed more frequently than the timeout, this order may be better:


Now logging can be disabled without specifying the timeout and retry count:


5. Real-life example: writing data to a BLE device

A BLE helper might require the following information:

• 
  []Characteristic UUID
  []Data to write
  []Whether the write requires a response
  []Timeout
• Whether the packet should be logged

Without optional parameters, we might have:


Every call must provide all five parameters:


However, most writes may use the same values:

• 
  []WithResponse = True
  []TimeoutMs = 5000
• LogPacket = True

With optional parameters:


The normal call becomes much cleaner:


For an unusual operation, all settings can still be supplied:


This is an excellent use of optional parameters: the common case remains simple while advanced cases remain configurable.

6. Real-life example: HTTP requests

An HTTP helper might originally look like this:


Even a simple GET request would require several values that may not be relevant:


With optional parameters:


A simple GET request becomes:


A POST request can be:


An advanced request can still provide all settings:


7. Real-life example: creating UI elements

A UI helper may contain many configuration parameters:


Every button would require a long call:


With optional parameters:


The common case becomes:


A customized button can still be created:


8. Real-life example: database queries

The original announcement includes an example similar to this:


A query without parameters can be called with:


A parameterized query can be called with:


A default result can also be supplied:


Before optional parameters, a developer might create several similar methods:


Optional parameters allow these variations to be represented by one cleaner API.

9. Adding new parameters without breaking existing code

One of the greatest benefits is the ability to extend a Sub without modifying all existing calls.

Imagine a project containing many calls to:


Later, cloud synchronization is added:


Without optional parameters, every existing call must be updated:


With an optional parameter:


All existing calls remain valid:


Only the unusual case needs the additional argument:


This will be particularly useful for:

• 
  []Large applications
  []Shared code modules
  []Cross-platform B4X code
  []Reusable classes
  []Libraries
  []APIs that evolve over time

Shorter calls are convenient, but being able to extend an API without changing dozens or hundreds of existing calls may be the most valuable benefit.

10. Using Null as the default value

An optional object can default to Null:


It can be called without an argument:


Or with a Map:


Using Null is useful for optional objects such as:

• 
  []Maps
  []Lists
  []Bitmaps
  []Callbacks
  []Configuration objects
  []Database arguments

However, omitting a parameter and explicitly passing Null are not necessarily the same operation.

For example:


These calls are conceptually different:


In the first call, the compiler inserts the default value of 10.

In the second call, the caller explicitly supplies Null.

The Sub should therefore define what an explicitly passed Null means.

11. This is a compile-time feature

Optional parameters are handled by the compiler.

Given:


When we write:


The compiler effectively treats the call as:


The Sub simply receives the final values. It does not need to determine whether the caller omitted a parameter.

Therefore, these calls are effectively equivalent:


12. CallSub and dynamically called Subs

Because optional parameter handling occurs at compile time, dynamic calls using CallSub still require the expected arguments.

For example:


A direct call can omit the second parameter:


However, developers should not assume that a dynamically invoked Sub will automatically receive its optional defaults.

Dynamic calls such as CallSub, CallSub2, and CallSub3 have their own fixed argument-count behavior.

Subs intended primarily for events, callbacks, or other dynamic invocation should therefore keep the required signature explicit.

13. Java library support

Optional parameters can also be exposed by Java libraries using the @DefaultValue annotation:


B4X code could then call it with only the byte array:


Or provide every setting:


The default value in the Java annotation is written as a string and parsed based on the parameter type when the library is loaded.

According to the announcement, expressions are not supported for defaults declared in Java or Objective-C libraries.

This should help library developers expose flexible APIs without requiring multiple nearly identical methods.

14. When optional parameters are a good choice

Optional parameters work well when:

• 
  []There is an obvious and safe default value.
  []Most callers use the same value.
  []The parameter controls advanced or less frequently used behavior.
  []A new capability is being added to an existing Sub.
  []Several similar Subs differ only by one or two parameters.
  []Omitting the value does not make the operation ambiguous.

Good examples might include:


15. When optional parameters may not be appropriate

Optional parameters should not be used when omitting a value could hide an important programming mistake.

For example:


A caller could accidentally omit the amount and silently transfer $1,000.

That is less of a default value and more of a booby trap wearing a necktie.

A safer design would require both values:


It is also wise to avoid creating Subs with too many optional Boolean or configuration parameters:


Even if the declaration uses optional parameters, a call containing a sequence such as:


is difficult to understand without looking at the Sub declaration.

At that point, an options type or configuration object may be clearer:


Example:


A reasonable rule of thumb might be:

• 
  []One to three optional parameters: usually clear and manageable.
  []Several Boolean configuration parameters: consider an options type.
  []Safety-critical values: make them required.
  []If a call contains a mysterious row of True and False values, the API may need to be redesigned.

Conclusion

Optional Sub parameters provide three major benefits.

1. Cleaner calls

Instead of:


We may be able to write:


2. Centralized default values

Default timeouts, retry counts, colors, logging settings, and other common values can be declared in one location instead of being repeated throughout the project.

3. Easier API evolution

An existing Sub:


can potentially be expanded without breaking its existing callers:


The main points to remember are:

• 
  []A parameter becomes optional when it is assigned a default value.
  []Required parameters must appear first.
  []Optional parameters must appear at the end.
  []Only trailing parameters can currently be omitted.
  []Middle parameters cannot currently be skipped.
  []Dynamic CallSub calls still require the appropriate arguments.
• Default values should be predictable and safe.

Overall, this is a very useful improvement to B4X.

It will make common calls shorter, reusable APIs cleaner, and existing projects easier to extend without modifying every call site.

It may not completely change the way we write B4X applications, but it should eliminate quite a bit of repetitive code—and fewer repetitive parameters means fewer opportunities to accidentally put True, False, or 5000 in the wrong position.

aeric said:

Imagine I have a sub for inserting or updating a row in database table.

B4X:

Sub Save (user_id As Int, user_name As String, user_age As Int, user_email As String, user_password As String, user_occupation As String)

End Sub

In the pass, I need to use Array, Map, custom type to create a cleaner sub with single parameter or leave empty Strings when call it. It looks ugly and may need more lines of code.

B4X:

Save(1, "John Cena", 21, "", "", "")

Now

B4X:

Save(1, "John Cena")

I think it is also useful for initializing values when create custom type.

B4X:

Type User (user_id As Int, user_name As String, user_age As Int, user_email As String, user_password As String, user_occupation As String)

Sub CreateUser(user_id As Int, user_name As String = "NoName", user_age As Int = 21, user_email As String, user_password As String = "default", user_occupation As String = "Actor")

End Sub

CreateUser (1, "John Cena")

Click to expand...

Thanks I think I understand this better.

And the defaults doesn't need to be constants:

really cool.
will it be possible to pass like 2 parameters but that are not following?

ilan said:

will it be possible to pass like 2 parameters but that are not following?

Click to expand...

No. It will be too confusing. How can the compiler / developer know which parameters are being set?

The Python solution for such cases is to use named arguments:

I don't think that it will be added to B4X.

Erel said:

No. It will be too confusing. How can the compiler / developer know which parameters are being set?

The Python solution for such cases is to use named arguments:

B4X:

anyfunction(num1=9, num3=20)

I don't think that it will be added to B4X.

Click to expand...

named arguments is the correct way or the only way i can think of making this possible is in events that have multiple types like: string, int, long,..

at least i think there needs to be like a way to add 2 parameters but keep a specific parameter with default value like:




if not it will only be possible to update the first parameter if you want to keep the others default

and the order of the structure must be very well thought when you create that function.

a syntex that tells the event to use the default parameter at that specific position will be a good addition