[Nitro] [PATCH][BUGFIX] Camel cases in class names are not handled correctly
bryan.a.soto at gmail.com
Wed Apr 5 18:21:08 EDT 2006
My solution was merely to generate the names in a consistent way. Two
different sections of code were arriving at a name in two different
ways. I chose to copy the way the field name was being created. :)
We really need to structure things better. There should be only one
place names are created.
Anyway, this is in regards to field names, not tables. I'm assuming
this means losing the module info isn't an issue since past Og didn't
use module names in fields. Though if someone can supply a test case
or something to show this is wrong, I'll cheerfully pull the patch.
This just happened to be the simplest thing I found to make the test
Are there any other thoughts on this? Perhaps I arrived at the wrong
solution? No one had any objections or comments, so I just went ahead
and applied it since it fixed a bug and closed a ticket.
On 4/5/06, TRANS <transfire at gmail.com> wrote:
> Not sure what your solution was. I notice the suggeston of using:
> I think #demodulize is really a misnomer. It is just an alias for
> #basename (and was derived from Rails). So you loose the module
> namespace of the class. Perhaps that it's what it desired, but might
> it not be dangerous?
> class Red::Fish
> class Blue::Fish
> Will both map to table 'fish', yes?
> If that's not what is wanted, you might try:
> #methodize is actually the opposite of modulize --hence why I think
> demodulize is a misnomer.
> Nitro-general mailing list
> Nitro-general at rubyforge.org
"Never tell people how to do things. Tell them what to do and they
will surprise you with their ingenuity." —General George S. Patton
More information about the Nitro-general