Support default arguments in function blocks

[pavi2410]

Describe the desired feature Allow components and extensions to define default values for any/all/none of the parameters.

Give an example of how this feature would be used This will ease the use of functions with many parameters. Users won't have to fill every parameter by themselves. This will also allow extensions to define a default argument for functions.

Why doesn't the current App Inventor system address this use case? It does with the Notifier.ShowChooseDialog block but that is hardcoded https://github.com/mit-cml/appinventor-sources/blob/cc121a481d7edd75878f24c3ccac70fa8584daa8/appinventor/blocklyeditor/src/drawer.js#L603

Why is this feature beneficial to App Inventor's educational mission? Make blocks easy to use and save users time.

[Vishwas-Adiga]

It might also be worth looking into using shadow blocks for these default parameters

[SuPythony]

@Vishwas-Adiga What are shadow blocks?

[ewpatton]

We have previously discussed using shadow blocks among the team and the power users. At the time we decided against it. At the very least, there are a number of changes here that need to be made to support annotating this information in the parameters and storing that information in simple_components.json. Drawer.js will also need to be modified to accommodate this. We'll also want to change the existing components to use this new approach rather than the special code paths currently used. All these things can be done before a decision on whether shadow blocks are used or not.

[ewpatton]

Before anyone takes on this task I'd prefer that we discuss the design first w.r.t. the annotations and changes to simple_components.json.

[halatmit]

Should we be asking people to create design docs?

== Hal

Hal Abelson hal@mit.edu Prof. of Comp. Sci. and Eng. MIT Dept. of Elec. Eng. and Comp. Sci.

On Thu, Jan 21, 2021 at 10:36 AM Evan W. Patton notifications@github.com wrote:

Before anyone takes on this task I'd prefer that we discuss the design first w.r.t. the annotations and changes to simple_components.json.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mit-cml/appinventor-sources/issues/2384#issuecomment-764727237, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGAXN522WDD5IXRVAVTDGLS3BCVVANCNFSM4WMSSPQQ .

[ewpatton]

@halatmit Yes, I'd like to see a more formal document of what this will look like prior to investing a lot of time implementing it.

@pavi2410 Do you have concrete thoughts on this? I have my own and can start drawing something up.

[pavi2410]

I do not have any concrete thought on this except a few ideas on the components side.

Here's how Thunkable X implements this using shadow blocks

[ewpatton]

I've started a design doc here: https://docs.google.com/document/d/1is90WHxQxX3g6wiq46Vnzb6QkDeX1e4tw7X1bBk2-pk/edit#

[pavi2410]

Could this be extended to support block properties as well? Or is it beyond the scope for now?

[ewpatton]

I'm not sure much if anything needs to be done for properties. We should be able to infer this information from the designer property default value and the type information for the property. I did a prototype of this back in 2017 in fact.

[BeksOmega]

Actually I think I did most of the work to support this last summer =) When I created the system to support dropdown blocks I tried to make it extensible enough so that new annotations could be defined and associated with new types of helper blocks (eg booleans, text inputs, etc). See my documentation on Adding New Types of Helper Blocks to the Blocks Editor. You should be able to create a parameterized annotation (representing a helper block) that takes in information about the default value and displays it on the helper block.

But I could also be missing the point of this issue hehe.

If I'm not missing the point, I recommend closing this issue in favor of creating issues for specific types of helper blocks & their associated annotations.

Also with regard to shadow blocks, during the summer I was told that the main issue with them was that they enlarged the save file size, because each shadow block needs to have at least two xml nodes associated with it (the block node and the field value node). There was a bit of talk about implementing some custom behavior so that shadow blocks wouldn't save their values (eg if you replaced a shadow with a real block, the shadow would forget the value input into its field) but we decided it was outside the scope of my summer project.

[ewpatton]

@BeksOmega Your documentation I do think is helpful for the annotations piece, but I am imagining that these would not be new blocks but that the engine would construct the constructor block for the given type (logic_boolean, text, math_number, etc.) rather than defining a brand new block.

[BeksOmega]

@BeksOmega Your documentation I do think is helpful for the annotations piece, but I am imagining that these would not be new blocks but that the engine would construct the constructor block for the given type (logic_boolean, text, math_number, etc.) rather than defining a brand new block.

Coolio, if I understand what you're saying, that should work fine! You'd just skip section 5 of the doc and move straight to section 6. For example:

Blockly.Util.xml.helperKeyToXML= function(helperKey) {
  switch(helperKey.type) {
    case 'OPTION_LIST':
      return this.blockTypeToXML('helpers_dropdown', {key: helperKey.key});
    case 'BOOLEAN':
      // You could either pass the default value as a mutation (like above),
      // and add a mutator to the logic_boolean block.
      // Or you could add a function to utils_xml.js to create field XML.
      return this.blockTypeToXML('logic_boolean');
  }
}

[pavi2410]

Question: Should we allow default values that are not primitive or complex?

IMO, we shouldn't. What is your take on this?

[BeksOmega]

Question: Should we allow default values that are not primitive or complex?

IMO, we shouldn't.

Hmm I don't really have an opinion. But I am curious, why don't you think they should be allowed? Is it just for XML size reasons, or is it something else? Also, just to be clear, by not primitive/complex do you mean things like lists/dictionaries?

[RajaHarshVardhanSolanki]

I want to give a proposal to the developers, It is very useful feature in Extension making, Set a default value of Property Blocks in @DesignerProperty.