[Proposal] No type given, assumes `_Nilable(_Any)`

[adrianthedev]

Hey Joel,

We are running into a few regressions since we implemented literal. They are type regressions, bot bugs from the gem, so not literal's fault 🙌.

We have quite a few _Nilable(_Any) declarations and I had this idea of what would literal look like if the default type declaration is that.

# this
prop :body

# is the equivalent of
prop :body, _Nilable(_Any)

Less characters to write; works better with the "no type" ruby way of doing things; more approachable to folks who only need to get rid of the initializer and will look for a gem to do that. It would increase adoption as well IMHO.

[stevegeek]

Thanks for the suggestion @adrianthedev ! Think this sounds like a good idea.

But maybe this could an be opt-in (or out) feature to let the gem consumer decide the level of strictness they wish to enforce on their prop definitions, ie in some of my projects I would consider a type-less prop declaration to be an error.

[adrianthedev]

Yeah. Makes sense for the more type-sensitive folks.

[joeldrapper]

I had wondered about this as it would make the library useful even for folks who don’t care about the type features. I quite like the idea of having strict and relaxed modes.

[hangsu]

in some of my projects I would consider a type-less prop declaration to be an error.

Agree with this sentiment. I would want this feature to be opt-in.

Also agree that literal has value outside of types. Our team never bike-sheds about what does and doesn't go into an initializer, and that's been quite valuable.

[joeldrapper]

I think we should implement this and make Literal more friendly out of the box. However, it should always have a strict mode that can be easily enabled.

[adrianthedev]

Yes, let's do this! And cut a release with the lazy-loaded types and the Nilable Any 😅 We're anxiously waiting for the new release so we can adopt the new features 🙌

[stevegeek]

What actually was our conclusion on if _Any includes nil? 😬😅

[joeldrapper]

I don’t know. I’ve mostly been convinced that _Any should include nil and it should be read as "any type" as opposed to "anything". But that leave us needing to come up with a name for anything-apart-=from-nil.

[adrianthedev]

@joeldrapper do you think there's a version of literal to be extracted in a different gem that doesn't handle the types at all and does not add the overhead?

the types are giving us too much trouble and we're pretty much set on migrating away from the strict types.

We just can't cntrol what the user might pass in.

[hangsu]

@adrianthedev why not just use ActiveModel::Attributes?

[adrianthedev]

Not sure if it supports everything we need like defaults and capturing **

[joeldrapper]

@adrianthedev it does support defaults. I’m not sure what capturing is.

[adrianthedev]

I mean capturin kwargs

class T
  def initialize(something, **kwargs)
    @kwargs = kwargs
  end
end

[joeldrapper]

@adrianthedev did you decide to go ahead with the fork? I think we should probably close this for now and maybe revisit it later if it comes up again. I’m not against it at all, but I just wouldn't use this feature myself.

[adrianthedev]

Yes @joeldrapper. We forked it here https://github.com/avo-hq/prop_initializer Thanks fro your help!