# Help repost to Ruby Dev -- 2 improvements to Ruby Magic **URL:** \ **Category:** Ruby\ **Created:** [June 6, 2007, 5:04am UTC](https://www.ruby-forum.com/t/help-repost-to-ruby-dev-2-improvements-to-ruby-magic/106072 "2007-06-06T05:04:05Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![thesunny](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thesunny](https://www.ruby-forum.com/u/thesunny)\ **Post date:** [June 6, 2007, 5:04am UTC](https://www.ruby-forum.com/t/help-repost-to-ruby-dev-2-improvements-to-ruby-magic/106072/1 "2007-06-06T05:04:05Z")
This is a proposed solution to simplify magic in Ruby. I’d appreciate it if somebody who has post access to ‘Ruby-core’ or ‘Ruby-dev’ could post this message there. Thank you in advance. If you get to read this Matz, thank you for bringing about such an excellent language. * * * I’m building a framework that has similarities to Ruby on Rails and Merb but targets the creation of website building software. In writing this software, one of the problems when reading other people’s code to get ideas is that it is difficult to find the magic methods. Of course, there are several types of magic but I’d like to propose solutions to help eliminate the confusion that two common types of magic cause. 1. Precede methods that are meant to be automagically called by ‘on\_’ Here are a few examples for the Ruby language: - on\_method\_missing - on\_initialize I consider them magic because they do something automatically and there is no direct call to either the ‘method\_missing’ or ‘initialize’ method. And for adding methods that are automagically called to a class: - on\_process - on\_before\_read - on\_after\_read - on\_before\_create - on\_after\_create When starting Ruby, it was difficult to know what the magic methods were and typically they were the last things to be mentioned in documentation (with the exception of initialize). They are second nature now but this naming convention makes it obvious that a method is a magic call making it simpler to learn the language for beginners. You just need to teach that ‘on\_’ means this method is called automagically in some way and from there you look up what the ‘on\_whatever’ call does. Also, consider the readability in the context of a lot of other methods. old way: - initialize - new - create - edit - post - validate - method\_missing new way: - on\_initialize - new - create - edit - post - on\_validate - on\_method\_missing In the second of the two lists above, it is obvious which methods get executed automatically. For example, you may have known ‘initialize’ and ‘method\_missing’ were, but there was probably no indication that ‘validate’ was called automatically. This is great for experienced users trying to quickly understand a class, but it is especially good for new users because they know that on\_method\_missing and on\_initialize are magically called methods, and that on\_validate is special in some way. One problem I had with reading through other source code was that it was difficult for me to tell where the entry points (magic methods) for the classes were without reading the RDoc. Locating the magic methods is time consuming, because you have to go through every method in the class. For example, Mongrel needs you to instantiate a handler class and then it calls ‘process’ when the handler needs to be executing. But reading the method names doesn’t help you without first knowing that the method ‘process’ is the entry point. If the Ruby standard was to start with ‘on\_’ and the method was named ‘on\_process’, you could find the entry point either almost immediately, or at least reduce your search to a small handful of magic ‘on\_’ methods. It was also difficult to find where magic methods were called from. This would be obvious if it was named on\_before\_read. This would allow for simple searching for the string ‘on\_’. I know its not foolproof searching, (e.g. may match ‘json\_read’ though you can get around this with a regex as well) but it makes our job a little easier. 1. Methods that are configuration should be preceded by ‘has\_’ I love Rails configuration but it is hard to find what framework code is configuration without first learning the entirety of the framework. The rails convention (to use no brackets for configuration) helps when reading code but only when you read/write code that uses the framework. It doesn’t help when trying to read/write the framework itself. Consider these methods in a class: - attr\_reader - has\_many - belongs\_to - initialize - helper - prepare\_stuff - before\_create - after\_read This is typically how classes read in Ruby. Now what about we rewrite this with our conventions - has\_attr\_reader (or has\_reader) - has\_children - has\_parent - on\_initialize - helper - prepare\_stuff - on\_before\_create - on\_after\_read It is clear now which methods are automagically called, which ones are configuration and which ones are POMs (Plain Old Methods). In fact, this would probably help us organize our code at the subconscious level too. Because I want to reorder my methods now to look nicer, though there is no requirement that I do (I know in some cases it is better to have the magic calls closer to related calls): - has\_attr\_reader - has\_children - has\_parent - on\_initialize - on\_before\_create - on\_after\_read - helper - prepare\_stuff One thing you may be thinking about with the ‘has\_’ convention is this: Will ‘has\_’ work for every type of configuration? The answer is, I think so. I went through a book on Rails (I think I own every Ruby and Rails book published including some online ones) to see if every instance of configuration could be rewritten with a ‘has\_’. I considered different prefixes but found that ‘has\_’ could be used in every case that I came across. In some cases, you had to be creative, but in no case was the name bad. In fact, I personally found that many of the names were better. Another benefit of standardizing on ‘has\_’ is that it makes all configuration method names consistent. For example, ‘attr\_reader’ is a noun, ‘has\_many’ is, well, some other part of the English language. Having consistency helps us better understand what configuration does which is it describes some aspect of a class. For this use, ‘has\_’ is a pretty good prefix. Finally, you may be concerned about my ‘opinion’ making its way into the language. Do the ‘on\_’ and ‘has\_’ changes really need to be made in the Ruby language itself? Isn’t Mr. Hirai just trying to force me to program the way he programs? Why doesn’t he just use it for himself? Well the answer is that I think it is important to have it in the Ruby language just like the convention for ‘?’ and ‘!’ on method name endings is used in the Ruby language. Nothing stops anybody from using the punctuation in other ways, but the convention in the base language has helped to make it work properly with all code. For example, if ‘!’ was used for exciting methods, the value of the ‘!’ would non-existent. It would just be another character in variable names. I know this sounds funny but try imagining that all automagic calls start with ‘on\_’ and ‘has\_’. Think of how much easier it would be to read code that involved callbacks and meta programming. If you are having trouble picturing the difference semantics make, think of how much more difficult life would be if Ruby did NOT have ‘!’ and ‘?’ for method names. In fact, that simple punctuation has solved many naming conflicts. Well, that’s it for now, but I’d be happy to discuss this more. This is a convention that I’ve already adapted for use in our web framework and it works. I’m also considering writing a new database abstraction library like ActiveRecord (but multi-threaded, connection pooling, multi-datasource, split-datasource for read/write, etc.) and would use it there… Again, if somebody has post access (or know somebody that does), I’d appreciate getting this in front of Matz and other contributors to the Ruby language. Sunny H. CEO, MeZine Inc. ---
**Author:** ![thesunny](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thesunny](https://www.ruby-forum.com/u/thesunny)\ **Post date:** [June 6, 2007, 9:55am UTC](https://www.ruby-forum.com/t/help-repost-to-ruby-dev-2-improvements-to-ruby-magic/106072/2 "2007-06-06T09:55:20Z")
Sunny H. wrote: > This is a proposed solution to simplify magic in Ruby. > > I’d appreciate it if somebody who has post access to ‘Ruby-core’ or > ‘Ruby-dev’ could post this message there. Thank you in advance. If you > get to read this Matz, thank you for bringing about such an excellent > language. I quite like this. I often feel that there’s not quite enough consistency in method naming. It’s more a problem in the stdlib than in core, though. The great thing about this specific proposal is that it’s completely (I think) implementable with aliases, so it needn’t break anything.