Wish "Default Parameter Value" of a SUB

[Sandman]

That looks more like an argument for named parameters

Let's save that backward compatibility-killing feature for some other thread.

 

[Magma]

This thread, is a thread that you can hate it and love it - the same time

But in reality... this is ("again") an example of different "brains"... how different "logic" - we all have..

 

[emexes]

Let's save that backward compatibility-killing feature for some other thread.

Yeah, but... if you squint at it from the other direction:

- named parameters, implemented "correctly" (?) encompass default parameters, so why not kill two birds with the one stone?
- they're only backward-incompatible if you start using the feature (in a Sub invocation) before they're implemented (in the Sub)

All five of these related features: variable number of parameters, default parameters, named parameters, variable parameter types, and variable number of return values, are pretty easy to do with Arrays and Maps of Objects, and more flexibly to boot (admittedly more wordily too). Especially now with ".As(Type)" and "GetType()" additions to B4X joining "Is Type".

And User-Defined Types have always gotten us half-way there anyway, if you don't need the "variable number of" aspect.

The main advantage I can see of Erel building it into the compiler is that static cases can be more efficient, eg having a single Bit.And function that works correspondingly with Byte/Short/Int/Long according to the parameter type(s).

I'm not even sure why I've written so much in this thread. Whatever Erel decides is the most effective use of time and energy, I'll be happy with. Overall seems like an approximately 50:50 decision to me. But then again, I'm a bit of a stick in the mud, eg, still doubtful about whether Smart String Literals and Designer Scripts were actually Great Leap Forwards, or just redundant alternative ways of doing things we were already comfortably doing.

 

[AnandGupta]

I understand most of the suggestion are from self developers, and 'default parameter' is not a problem here then.
I too do not need it for my self developed and maintained Android app in B4A.

My juniors working under me, in our company, and using my classes, subs, library etc. are not well versed with B4X.
All have knowledge of dot.Net, FoxPro, Clipper etc.

I guide them to develop project just as they have been, in B4X too. I create library for them for developing projects for our company.
They are accustom to having 'default parameter' subs in dot.Net, FoxPro, Clipper etc.
I just can not tell them to use different subs for different parameter requirements.

This is one more reason why our company requested (putting it humbly) to start projects in C#, and the reason of my learning C# in the first place.

 

[Sandman]

For whatever it's worth, I suppose I should point out that I'm a solo developer, so it's not only useful for team scenarios.

 

[AnandGupta]

Let's see which way Erel blows.

Yes. It is his calling now, for B4X.
Let us wait.

 

[Magma]

Yes. It is his calling now, for B4X.
Let us wait.

Hey guys.. it is a nice feature to add... but not a decision of life.. do not make it a drama if not get it...

 

[AnandGupta]

do not make it a drama if not get it...

No chance. I failed in screen test once.
Programming is easier, with B4X

 

[Magma]

No chance. I failed in screen test once.
Programming is easier

You "must" edit that... programming is easier with B4X... (you will have more likely possibilities.. you know for what)

 

[AnandGupta]

You "must" edit that... programming is easier with B4X... (you will have more likely possibilities.. you know for what)

Oh yeah ! Done.

 

[Magma]

That's better

 

[Magma]

I feel like you are "ready" for audition...