Add lazy versions of Object#getter?/property? macros

[Sija]

This PR adds lazy initialized versions of Object#getter?/property?. They do exist for getter/property macros, so that would bring feature parity to both variants.

Possibly closes #7321

[ysbaddaden]

A foo? getter with a lazy initializer will always initialize a value and never return nil, whatever if I did set it to nil. Or am I missing something?

At least, it should memorize whether the value has been initialized (which can be nil).

[Sija]

A foo? getter with a lazy initializer will always initialize a value and never return nil, whatever if I did set it to nil. Or am I missing something?

I'm not sure if I follow... Using nil-able types for any of the property/setter macros would result in re-initialization of the value inside getter on every call. This PR doesn't change that. IMHO that's a very rare edgecase, there's no need to support, at least not atm.

class Foo
  getter?(installed : Bool) { true }
end

foo = Foo.new
p foo.@installed # => nil
p foo.installed? # => true
p foo.@installed # => true

foo.installed = nil
p foo.@installed # => nil
p foo.installed? # => true
p foo.@installed # => true

[ysbaddaden]

That's exactly my issue: what's the difference between getter?(foo) { } and getter(foo) { } in this patch? The foo? method is supposed to return a nilable, but it will always (re)initialize the variable, thus never return a nilable value, which is the behavior of the foo method. That's confusing.

Unless there are actual use cases that I'm obviously missing? The whole patch looks like a very edge case to me. I'm not sure that getter?(foo) { } should compile at all.

[j8r]

Yes I was suggesting what @ysbaddaden says. Else, this ? variants won't add much compared to non-? macros.

[j8r]

To know if the nillable variables was lazily initialized with the block, a second boolean variable has to be used.

My use case here is to detect the Init system of the machine. I don't want to repeat the operation, and it can return nil if the init system is unsupported. It shouldn't raise because the program can still work without.

[Sija]

The foo? method is supposed to return a nilable, but it will always (re)initialize the variable, thus never return a nilable value, which is the behavior of the foo method. That's confusing.

@ysbaddaden I think there's some misunderstanding about the use cases for getter? methods - as I see it + is stated in api docs - getter? macro is used to generate query methods - usually returning Bool, not as nilable version of regular getter.

[ysbaddaden]

A lazy initialized boolean getter method just makes no sense to me at all. I can't see any use case 😕

[RX14]

@ysbaddaden a boolean's just another return type, it could be computed from the network, or some other expensive operation which is best done on-demand.

[Sija]

@ysbaddaden One example comes from shards (sic!):

https://github.com/crystal-lang/shards/blob/a2a5e7990ab9a234bea8fbcaea521cc98513607f/src/resolvers/git.cr#L18-L23

[j8r]

Since #7313 is merged, what brings this implementation vs. regular getter and property, despite the ? at the end of the method name?

[Sija]

@j8r As I said before: it brings feature parity (lazy block initialization). ? at the end of the method name is the difference between getter/property and getter?/property?, has been since before, and this PR doesn't change that.

[sdogruyol]

Thank you @Sija 👍

[Sija]

@asterite Would you care for a review (& merge if all's good)?

[asterite]

Sure, I'll do it in max 3 days.