It occurs to me that you can override Class.new to do this and make a much cleaner API. Any reason not to do this regularly? Feels weird to return `nil` from a constructor, but it would be darn handy a lot of times. https://gist.github.com/davetron5000/1a6b394f4295f1b70062baab013d297f#file-new-rb - ThreadSky

davetron5000.com • 13 days ago

It occurs to me that you can override https://Class.new to do this and make a much cleaner API.

Any reason not to do this regularly? Feels weird to return `nil` from a constructor, but it would be darn handy a lot of times.

https://gist.github.com/davetron5000/1a6b394f4295f1b70062baab013d297f#file-new-rb

Comments

joel.drapper.me•12 days ago

I would be very surprised/disappointed if calling .new returned nil instead of either raising or returning an object of the class, personally.

joel.drapper.me•12 days ago

I usually use `.coerce` for things like this.

It’s also nice to map the `.to_proc` class method to `method(:coerce).to_proc`. It lets you do something like `array_of_values.map(&YourClass)`.

soulcutter.com•12 days ago

> map the `.to_proc` class method to `method(:coerce).to_proc`. It lets you do something like `array_of_values.map(&YourClass)`

This is brilliant. I'm going to use this.

joel.drapper.me•12 days ago

We use this for Literal::Enums

davetron5000.com•12 days ago

I cannot find the explanation of coerce - just some method definitions that don't explain why they do what they do. Do you have a handy explainer and/or reference?

joel.drapper.me•12 days ago

It’s just a method I implement instead of overriding .new.

davetron5000.com•12 days ago

Ah, OK - apparently there is a whole Ruby coerce protocol thing: https://stackoverflow.com/questions/2799571/in-ruby-how-does-coerce-actually-work

fxn.bsky.social•12 days ago

Agree.

Another option would be to make `new` private in a hierarchy for which that is natural, and have only `MyRoot.from` in the root class.

joel.drapper.me•12 days ago

Very good point. Making `.new` private is a useful technique.

davetron5000.com•12 days ago

Yeah I think this is why I will not adopt this pattern ultimately. It’s too weird to not get and object back if the expected type.

fxn.bsky.social•12 days ago

Yes, also weird to return the argument back verbatim instead of a brand new object.

That is logic one can define ad-hoc for a custom method that has a different name, it is custom, so you set the rules, but I think people would get confused if `new` did that.

davetron5000.com•12 days ago

Yup. What’s interesting about this from a meta perspective is that this is all cultural. In eg Java this is a rule you cannot break technically but Ruby it’s more about being a good citizen.

noelrappin.com•12 days ago

Yeah, I write code like this all the time but I don't call it `new`, I usually call it `for`, as in `Widget.for(thing)`

skillstopractice.com•13 days ago

I think the pattern looks helpful.

Something implicit about the contract for new() is that I would expect a newly allocated object with a distinct object id even if the data wasn't necessarily deep copied.

But a new!() Or build() method that does the same thing seems good!

skillstopractice.com•13 days ago

Another possibility here is that I am a big fan of using the [] operator at the class level as a wrapper around the constructor.

So... using that approach, you'd get:

Header[nil] -> nil
Header["something"] -> Header<"something">
Header[some_header] -> some_header

chastell.net•12 days ago

my fav thing is if you make `#inspect` match it you get copy-paste strings from logs, exceptions, etc. that you can drop straight into irb

katafrakt.bsky.social•13 days ago

One of my first blog posts ever was about overriding "new" 🙃

https://katafrakt.me/2015/05/15/when-you-call-object-new/

It does indeed feel a bit weird to return nil from that. I would expect some kind of an object always. But in principle I don't think the practice is bad.

Comments

Posting Rules

Reply