virtual Obj? trap(Str name, Obj?[]? args)

change to

virtual Obj? trap(Str name, Obj?[]? args := null)

What problem does this solve?

This is save six keystrokes!

context.trap(name, null)

vs

context.trap(name)

+1, default value is needed. Basically direct call to trap is sort of reflection for dynamic invocations. For example, I have a Json object (map with overrided trap) and use it like this:

json := ConstJson.makeWith { it->a = 4; it->b = "foo" }

So in all cases when I know the name, everything is fine, I use -> and don't care about default parameter. Buf if names are coming from somewhere, I need to either expose map from my json obj, or call trap directly.

Some random example: imagine I need to get certain fields from list of objects and display them in a table, I have to write something like this:

Void dump(ConstJson[] objs, Str[] names, Buf out)
{
  out.add("<th>").add(names.map { "<td>$it</td>"}.join).add("</th>")
  objs.each |obj|
  {
    out.add("<tr>")
    names.each |name|
    {
      out.add("<td>").add(obj.trap(name, null)).add("</td>")
    }
    out.add("<td>")
  }
}

Another thought on trap - probably it could be better to have separate methods like trapGet, trapSet and trapCall:

• Such separation needs to be done in overriden trap manually in most cases
• Right now inside the trap we can distinguish getting from setting and calling just by arg count. However there's no direct way to separate setter and call.
• Compiler already has all this information, so it should be easy

Another thought on trap - probably it could be better to have separate methods like > trapGet, trapSet and trapCall

Not really. trapGet and trapCall with no parameters are intentionally indistinguishable, so that we could override no-param method with a field.

out.add("<th>").add(names.map { "<td>$it</td>"}.join).add("</th>")

Actually, th is a replacement for td, not tr. I think you want

out.add("<tr>").add(names.map { "<th>$it</th>"}.join).add("</tr>")

If W3 Schools is to be believed. Nice use of map and join, though.

Renamed from **[idea] add default to parameter args in Obj.trap** to **Obj.trap support for default args of null**

Promoted to ticket #1363 and assigned to brian

I made two changes regarding this issue:

1. Obj.trap now defaults the args parameter to null when using trap explicitly
2. Compiler now passes null for x->y and x->y() when there are no arguments

The second fix is an optimization since previously I was actually allocating an unnecessary empty list. Might be a gotcha for some trap implementations that weren't handling null correctly.

Ticket resolved in 1.0.57

What about empty list const? like List.empty

virtual Obj? trap(Str name, Obj?[] args := List.empty)