21–26 of 26 posts
Back in the day I recall that NotImplementedError was used for metaprogramming dynamic methods - in particular the ActiveRecord helpers that translated to semi-natural language based on fields in the db... it would try to create the method on the fly if the fields existed and the convention was adhered to, otherwise it would rethrow. I don't believe those are supported anymore.
Earlier quoted context omitted.
It's Ruby, there's no compilation. It's also common to not load all files of an application's codebase at startup, in particular this is the default setting for Rails in development mode.
There is. CRuby code gets compiled to ISeq (VM bytecode) upon `load` / `require` / `eval`. JRuby does similar things (IIRC using InvokeDynamic). The difference (and that does not even need to involve Rails) is that these three - and thus compilation - happen at runtime , anytime, always. The fact that a typical "main" file follows the "require first, then define modules and classes, then execute" creates a mental ill…
I think that NotImplementedError doesn't get rescued is a feature, not a bug. It means you are calling a class that has a missing part of the interface, and that's usually programmer error. For some cases where you can partially implement the spec, it may make sense to go this way, but for most abstract classes I think the NotImplementedError is still a good idea.
I have always been unconvinced of the value of doing Java-style abstract classes to assert a certain API in Ruby considering it's duck-typed. Raising an error when at runtime you call a nonexistent method is native Ruby behavior, so why write methods that say "I don't exist"? If doing this added in any build-time guarantees that you have to implement that method they'd be great, but as used they're just additional co…
> Ruby also provides inheritance hooks that could conceivably be used to detect the existence of methods at load time
This misses numerous corner cases e.g. refinements, or the dynamic include/prepend of modules (which may even be generated anonymous modules). One may not write such code often in applications, but this happens routinely in the guts of many frameworks and libraries, and not just Rails.
Most attempts to introduce type checking or anything resembling it into Ruby run into the wall of "load time is run time".
___
[1] corollary: consider writing a respond_to? that returns false for the abstract method(s)
Back in the day I recall that NotImplementedError was used for metaprogramming dynamic methods - in particular the ActiveRecord helpers that translated to semi-natural language based on fields in the db... it would try to create the method on the fly if the fields existed and the convention was adhered to, otherwise it would rethrow. I don't believe those are supported anymore.
You are thinking of method_missing. It’s an entirely different thing.
`UndefinedMethodError` perhaps? that way we can restore the distinction between method declaration (which assigns a name, within some namespace) and method definition/implementation which gives the function its ability.
Wouldn't that be too similar to NoMethodError? I recently came across the idiom in Smalltalk, where you would call subclassResponsibility: someMethod: self subclassResponsibility I've suggested the name in the ruby bug tracker issue here: https://bugs.ruby-lang.org/issues/18915