Hi,

Quick check - I feel like there's an easier way to do this (allow the use of nothing, config.props or runtime arguments -- in that order of precedence) but I'm not seeing it.

class Main : AbstractMain
{

  const Int defaultPort := 8080
  const Int? configuredPort := typeof.pod.config("port")?.toInt
  @Opt Int port := configuredPort ?: defaultPort

  const File defaultLogDir := homeDir + `/logs`
  const File? configuredLogDir := typeof.pod.config("logDir")?.toUri.toFile
  @Opt File logDir := configuredLogDir ?: defaultLogDir

  // Repeat for everything else
}

Is there a simpler way to get at what I'm looking for without the repetition?

M

I think I would combine it all into one line like this

@Opt Int port := typeof.pod.config("port", "8080").toInt

I did have it that way initially - but then the logDir example started to get a bit nasty.

@Opt File logDir := typeof.pod.config("logDir", (homeDir + `/logs`).toStr).toUri.toFile

Which was a bit convoluted for my taste

Ta

Also (should probably put this in a separate thread) - my initial take had something like the (simplified) following:

// Given
Str? a
Str b := "/"

// Doesn't compile - complains that the left hand side being non-nullable
File c := a?.toUri.toFile ?: b.toUri.toFile

// Instead need to do (note the second use of ?.)
File c := a?.toUri?.toFile ?: b.toUri.toFile

Seems as though elvis's "is it null" checking isn't following all branches of the safe invoke to determine whether the LHS is nullable?

M

Seems as though elvis's "is it null" checking isn't following all branches of the safe invoke to determine whether the LHS is nullable?

That is by design - each level of the call chain must explicitly design whether to handle null or not.

I'm still a little lost (thought I had it straight in my head but it keeps hurting...) If I have a line:

Str? a := obj?.toStr.upper

Then I expect (and I'm probably wrong) that something like the following occurs:

Srr? a
if (obj != null)
  a = obj.toStr.upper

At which point a may or may not be null. This can then be used with the Elvis operator (assumption: can't test it right now):

Str b := a ?: Str.defVal

However if I inline the statement as per the example above it fails:

Str b := a?.toStr.upper ?: Str.defVal

The only way I can think of wanting multiple ?.'s inline is if the return values are nullable.

Then I expect (and I'm probably wrong) that something like the following occurs:

?. is syntactic sugar working this way

obj?.slot ==> obj==null ? null : obj.slot.

So in your example it will be

Str? a
if (obj != null)
  a = obj.toStr.upper
else
  a = null.upper

Which leaves us with 2 possible outcomes: a is not null or NullErr.

facepalm*

No idea why I read (or interpreted)

If short circuited, then the whole expression evaluates to null.

As short circuiting the entire statement rather than just the expression...

Too much time in meetings killing off productive brain cells!

Thanks for clarifying

Here is one good way to think about it:

a.b.c    =>  (a.b).c
a?.b.c   =>  (a?.b).c
a?.b?.c  =>  (a?.b)?.c

Shouldn't the second form of these three be prohibited? Of course:

a.b

where a is a nullable type, should not be prohibited. However, I feel a?.b.c is actually admitting that a?.b can return null, so a?.b.c is quite likely to throw a NullErr at some point.

Also:

a.b?.c   =>  (a.b)?.c

Actually I think I did that check for Sedona when I added the ?. operator, but with Fantom there some reason that I held back. I will need to revisit, seems like a good idea.

For the record I also use to think that a "failed" ?. would short circuit the rest of the expression, until Brian pointed out it doesn't at some point.

I often think the "short circuit" feature would actually be really cool and useful.

Yes, but remember that it is an expression, so it msut always result in a value (or an error). You seem to assume that the invokation would return Void.