It's overloading the invoke( () -> { }) operato...
# announcements
a
It's overloading the invoke( () -> { }) operator with a trailing clojure.... Which may be confusing in itself so opinions are welcome
r
arocnies: Since the block is acting on a
FileBrick
and not a
String
, I'd say just leave it as it is.
a
I saw your comment about
"foo".state = ...
but I can't find it now.
r
I misread your comment and gave bad advise, so I deleted it. Sorry for the confusion.
a
Oh no worries. That actually looks like a potentially good option to me. Maybe I'm missing it's cons?
r
With my deleted suggestion, you would no longer be operating in the context of
FileBrick
so you wouldn't have access to
state
or
copyOf
.
Also, since the
FileBrick
is created in the block, creating a
var String.state
wouldn't work since you can't really define a logical getter for it. Unless I'm wrong in assuming
state
is a property of
FileBrick
. If it isn't, there could be clean ways to do it.
a
state
is a property of
FileBrick
. Hmmm. I think it's starting to make sense. I think I need to experiment a bit to fully understand the implications of using String.state
Ah okay. Now I think I understand what you mean.
I did find a way to make
file {  "/etc/foo".state = copyOf("foo")  }
But it's messy. And now using an infix function looks better. Thanks for the help. I'll probably keep it as it is for now
r
Sounds good