Wish "Default Parameter Value" of a SUB

[AnandGupta]

Erel would see it as an unnecessary complication to what is intended to be a straightforward language.

Well, I hope Erel may see it as added advantage of using B4X in a team, where a senior is not forced to add suffix to Subs just to add a parameter.
It does not look good to dictate the juniors to use different Subs for different parameters requirements.
Still he has full right to decide the course. ?

 

[agraham]

I don't understand this reasoning. You don't need different Subs, you just need a single one with all the necessary parameters and pass default values yourself. I just fail to see any benefits for default parameters.

 

[AnandGupta]

you just need a single one with all the necessary parameters

Please see my reply for similar suggestion.

"Default Parameter Value" of a SUB

I was going though C# course and found "Default Parameter Value" static void MyMethod(string country = "Norway") { Console.WriteLine(country); } static void Main(string[] args) { MyMethod("Sweden"); MyMethod("India"); MyMethod(); MyMethod("USA"); } // Sweden // India // Norway //...

www.b4x.com

Again I repeat. I am making a wish here and have explained the reason for it.
Rest is on Erel wisdom and time.

 

[Magma]

I think that in case including default value.. it will be good to add and null-clear value...

but as I am thinking it more... will make the things complicated... and now I understand Agraham's post.

 

[Sandman]

I don't understand this reasoning. You don't need different Subs, you just need a single one with all the necessary parameters and pass default values yourself. I just fail to see any benefits for default parameters.

So you basically say that the languages that were designed like this did something they don't actually need, because they should just pass the default values themselves?

 

[Magma]

So you basically say that the languages that were designed like this did something they don't actually need, because they should just pass the default values themselves?

I think agraham said that you can pass those default values from one sub...

SetdefaultsforGps... for example...

As I can understand...


About languages had it... it is nice but it was an option from the beginning.. i think.

 

[agraham]

So you basically say that the languages that were designed like this did something they don't actually need, because they should just pass the default values themselves?

Basically yes. I think this particular feature is obscurationist rather than helpful because it requires you to 'know' that there is a default parameter that the Sub is using rather than the parameter list being obvious from the Sub signature. Either a parameter should be obvious in the signature, or a constant in the Sub. I personally don't think hiding parameters is a good thing. If you want defaults declare them as constants and pass them explicitly yourself so it is obvious.

But then that's just my own old-fashioned opinion. I like to see what a language is doing in the simplest possible manner.

 

[Magma]

Dim..private...constants... ofcourse...

 

[Sandman]

I think this particular feature is obscurationist rather than helpful because it requires you to 'know' that there is a default parameter that the Sub is using rather than the parameter list being obvious from the Sub signature. Either a parameter should be obvious in the signature, or a constant in the Sub. I personally don't think hiding parameters is a good thing.

Now there, I don't think anyone here tried promoting "hiding parameters". That seems a bit unfair to label it as such.

It seems to me that your argument could be rephrased to "I don't like default parameters because they won't show up in the sub signature". To me, that indicates that you perhaps haven't thought through how the IDE actually could present this to the developer. I can't think of a single reason why it would make sense for the IDE to actually hide any parameters from the signature. Just show the ones with default values in some way that makes it clear they are optional, and what the default values are instead.

As a reference, I did a quick search online and found how PHPStorm does it for php. The example isn't super clear, but that's the best I could find at the moment; I'm not at my workstation now. We can see that the last parameter is optional, and null if not provided.

This is all academic, of course, as I can't imagine Erel adding the feature. And that's fine, I'll survive.

 

[Magma]

This is all academic, of course, as I can't imagine Erel adding the feature. And that's fine, I'll survive.

I hope... that ?... for all of us..

 

[agraham]

To me, that indicates that you perhaps haven't thought through how the IDE actually could present this to the developer.

Don't accuse me of not having thought through anything related to a programming language. I've been coding for more than 55 years now and have an interest in compiler design and language structures and I've been through a lot of them including writing my own assemblers, compilers and interpreters. After all this time my experience tells me that simple is best and once beyond a certain maturity 'official' languages tend to accrete features that seem to be there because someone thought it was a clever addition - C++ Shudder!

We may differ in opinion but don't tell me I haven't thought anything through!

 

[AnandGupta]

Looks like we are straying from the path here.

Let me put forth real life example of programming language here.
I have developed in Clipper 87 (if some one remembers it here) and it did not have 'default parameter'.

So we had to pass all the required values, no matter how many parameters were there.
Then came Clipper 5, and it gave 'default parameter' as added feature.
See below,

MemoEdit()

Displays and/or edits text or memo fields. 
MemoEdit( [<cString>]   , ;
          [<nTop>]      , ;
          [<nLeft>]     , ;
          [<nBottom>]   , ;
          [<nRight>]    , ;
          [<lEditMode>] , ;
          [<bcUserFunc>], ;
          [<nLineLen>]  , ;
          [<nTabSize>]  , ;
          [<nBufferRow>], ;
          [<nBufferCol>], ;
          [<nWindowRow>], ;
          [<nWindowCol>]  ) --> cTextBuffer

Parameters 
<cString> 
<cString> contains a character string or the contents of a memo field. 
<nTop> 
<nTop> is an integer numeric value specifying the top screen row at which the edit window is displayed
<nLeft> 
<nLeft> is an integer numeric value specifying the left screen column for the edit window display. The default value is zero. 
<nBottom> 
<nBottom> is an integer numeric value specifying the bottom row for the edit window display. The default value is MaxRow(). 
<nRight> 
<nRight> is an integer numeric value specifying the right screen column for the edit window display. The default value is MaxCol(). 
...

Clipper gives NIL for not passes parameters. It helps the developer to use the language more efficiently.
Similarly if B4X can give NULL for not passed parameters, we can use it for our own default values for the Sub.

 

[AnandGupta]

We also have For-Each along with For-Next, in B4X.
Because, For-Each simplifies, though same can be achieved with For-Next

 

[AnandGupta]

And Erel did add IIf(,,) in B4X now. Just to simplify the If-End If structure.

I hope we can see the B4X does helps in many places just like Clipper (It already has IIF() and ++ etc.)
So my request is for 'Default parameter'

 

[Sandman]

Don't accuse me

I have no interest in getting into a fight here, but I'd recommend reading my text again. At no point did I accuse you of anything.

If anything, I consider myself humble and aware that I might be wrong. And I've several times in the forum made it clear that I code mostly with my elbows and rely on luck to get an app compiling. But it sure seems nice to have so much experience that you can say with absolute certainty what is right and wrong.

As far as C++ is concerned I have to admit I wouldn't be able to pick it out of you place it next to C, C+ and C+++. As with most of the things I'm not competent with, I tend to trust people who have thought things through. Such as John Carmack (famously coded Doom, Quake etc) when he said he disliked C++ quite a bit. So, pretty much the same reasoning as I apply when considering the feature discussed in this thread. A lot of smart people, working on other languages, thought it would be a good idea to have default parameters. As a developer I find they simplify my life quite a bit. Seems good to me.

 

[Magma]

.......Now... about the path (like my friend AnandGupta said) we had...

I think if it is optional (can't say how will be)... will be good to added also adding what will be the null/clear value (for example if somewhere we are setting a string with "Last name of a person", may be we need to have the null of string as "uknown")... but if that change the whole structure and hide other things that "we" can't imagine... no prob to stay... as we are now......

It seems that this will add parameters... and if's...

 

[emexes]

I just fail to see any benefits for default parameters.

At the risk of drawing friendly-fire: I think @AnandGupta gave an example of a benefit, being when shared code is extended eg:

Sub AnswerToLife(Par1 As String, Par2 As Int)

has some extra functionality added which requires adding some extra parameters eg:

Sub AnswerToLife(Par1 As String, Par2 As Int, Server As String, Operator As String)

which causes all the existing calls to that Sub/Method, in programs written previously, to fall over at next compilation (or sooner, with runtime/dynamic linking).

If the two added parameters were optional and had workable default values, then existing programs would continue to work.



Personally, though, I'd just do this... make the new improved Sub be:

Sub AnswerToLifeAndEverything(Par1 As String, Par2 As Int, Server As String, Operator As String)

and make the previous Sub be:

Sub AnswerToLife(Par1 As String, Par2 As Int)
    AnswerToLifeAndEverything(Par1, Par2, "Deep Thought", "Benjy")
End Sub

which I think will resolve 95% of the actual real-world issues here. Sure, you've got two subs now, and you had to think of an new enhanced Sub name to match the enhanced functionality, but... that's more good than bad, I think. And it certainly makes it more easier and straightforward to do stuff like:

Sub Globals
    Dim UsedOldSubFlag As Boolean = False
End Sub

Sub AnswerToLife(
]Sub AnswerToLife(Par1 As String, Par2 As Int)
    If UsedOldSubFlag = False Then
        SystemLog("Hey, this Sub AnswerToLife is deprecated, you might want to consider moving to current Sub AnswerToLifeAndEverything")
        UserLog(Chr(7) & Chr(7) & Chr(7))    'if the klaxons don't get the user's attention
        Sleep(10000)    'then a delay certainly will
        UsedOldSubFlag = True
    End If

    AnswerToLifeAndEverything(Par1, Par2, "Deep Thought", "Benjy")
End Sub

yes, I know about the more easier bit

 

[emexes]

So you basically say that the languages that were designed like this did something they don't actually need, because they should just pass the default values themselves?

I think you basically just answered your own question there.

I agree that it's a nice feature, but for the occasions where it's actually needed, named parameters are usually a better solution, and I cheerfully admit that many of my old kludgy Array As Object workarounds, which rely on knowing the parameters and order - ie just like regular Sub parameters - would be better as maps

 

[emexes]

Let me put forth real life example of programming language here.

MemoEdit()

Displays and/or edits text or memo fields.
MemoEdit( [<cString>]   , ;
          [<nTop>]      , ;
          [<nLeft>]     , ;
          [<nBottom>]   , ;
          [<nRight>]    , ;
          [<lEditMode>] , ;
          [<bcUserFunc>], ;
          [<nLineLen>]  , ;
          [<nTabSize>]  , ;
          [<nBufferRow>], ;
          [<nBufferCol>], ;
          [<nWindowRow>], ;
          [<nWindowCol>]  ) --> cTextBuffer

That looks more like an argument for named parameters, or practicing comma-counting skills. ?

 

[Sandman]

I don't want to add more fuel to this already overly heated thread, I just want to add a better illustration of how the IDE can display optional parameters, and their default values. The image I pasted above wasn't all that simple to understand, sorry about that. All this is php code, as displayed using VS Code when one have the PHP IntelliSense extension loaded.

Here's the function:

And here's what VS Code shows when coding: