Cobra Forums

t.sort(do(a as int, b as int)=a.compareTo(b))

t.sort( { a,b | a.compareTo(b) } )

t.sort( { a as int,b as int | a.compareTo(b) } )

.callArithmeticOp(3, 4, {a as int, b as int|
            return a * b})

# For reference, here is a named method declaration:
    def foo(a as int, b as int)
        pass
# Let's start with anonymous methods which are obviously methods without names. 
# So an anon. method could be:
    def (a as int, b as int)
# But I chose 'do' as the keyword because I thought it read better in code:
    do(a is int, b as int) ...

# The lack of inference on the arguments is a gap in Cobra, not a design point.
# Assuming it was supported, we are really comparing:
    customers.sort(do(a, b)=a.name.compareTo(b.name))
    customers.sort({ a, b | a.name.compareTo(b.name)})

# The difference is not great and the first fits in better with Cobra's use of keywords to start things off
# as well as it's existing 'def' syntax which uses an argument list in parens.

# Also, the second introduces new overloading on {} and |,
# although that's a minor point.

# I do occasionally imagine possibilities like:
    customers.sort(on .name)
# That reads well and 'on' is already reserved.
# I haven't thought through the full implications
# or decided if it's worth having special language syntax just for .sort arguments.