# Dynamic class thingies? (Okay, not sure how to title this one)

**URL:** <https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275>\
**Category:** Ruby\
**Created:** [March 7, 2008, 4:06pm UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275 "2008-03-07T16:06:45Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 7, 2008, 4:06pm UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/1 "2008-03-07T16:06:45Z")

</div>

Asking for ideas here but let me preface…

There’s an application with a sqlite3 database that I’m building Ruby  
classes and methods for accessing. ActiveRecord was close but no cigar  
because I have no control over the database and there are quirks in  
there  
I want to “hide”. Besides, I’m still newish to Ruby and want the  
exercise  
of doing it myself even at the risk of re-inventing the wheel.

Okay so tables are objects and rows are objects. I have a table class  
and  
a row class and specific tables and rows inherit from them. At the end,  
you get nice little methods like:

table.find(some\_search\_criteria)

that returns an array of row objects.

Over time, as I’ve worked on this and picked up more on Ruby, I’ve been  
moving more things up into the table superclass. Noticing as I’ve gone  
along that a great deal of code was identical in the subclasses. I’m  
actually down to something fairly simple that takes the array of records  
(an array of hashes actually) sqlite returns and “packages” them into  
row  
objects then returns them.

This code is pretty much identical in all cases _except_ that the row  
objects are different. That is, something like this in the subclass:

def find(criteria)  
results = []  
do\_find(criteria).each { |res|  
results \<\< Transaction.new(res)  
}  
return results  
end

“do\_find” being inherited and containing all the contortions and hoop  
jumping that results in a SQL statement from the “criteria”.

The only difference now between the different subclasses is the line:

```
results << Transaction.new(res)

```

Such as, say there’s a table for “accounts” then the line is:

```
results << Account.new(res)

```

The table classes are plural (rather Railsish I guess ) of the row  
classes. Transaction being the row class, Transactions being the table  
class, etc.

So it occurs to me that deriving the row class from the name of the  
table  
class is trivial. So I could generalize this all even further if I could  
figure out a way to create a new row object of the class that is  
singular  
of the table class.

Having bopped about Ruby a while now, I have a sneaking suspicion  
there’s  
a way to do this. If I “self.class” in the superclass’ code, I’m getting  
the name of the table instance (“Transactions” for instance). I can…  
what’s the word… “singularize” (?) it and have “Transaction” so I know  
the name of the row class I need to instantiate.

But there I’m stuck. I have the name of the class as a string but that  
doesn’t do me any good. I keep thinking (and have been digging through  
several Ruby books but I’m not tumbling to this yet) that there’s some  
way to do something sort of:

results \<\< magical\_thing\_here.new(res)

Where “magical\_thing\_here” takes that string and lets Ruby know I mean  
“this is a name of a class”.

What am I missing?

I mean, besides a lot more experience with Ruby.

---

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 7, 2008, 4:13pm UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/2 "2008-03-07T16:13:15Z")

</div>

Alle Friday 07 March 2008, coigner ha scritto:

> you get nice little methods like:  
> objects then returns them.  
> end  
> results \<\< Account.new(res)  
> Having bopped about Ruby a while now, I have a sneaking suspicion there’s  
> results \<\< magical\_thing\_here.new(res)
> 
> Where “magical\_thing\_here” takes that string and lets Ruby know I mean  
> “this is a name of a class”.
> 
> What am I missing?
> 
> I mean, besides a lot more experience with Ruby.

You want Kernel.const\_get. As the name suggests, it takes a string and  
returns  
the value of the constant with that name. For instance:

class C  
end

Kernel.const\_get(‘C’).new  
=\> #\<C:0xb7c55064\>

If your classes are defined top-level, that’s all you need. If they’re  
defined  
inside a module, you need to call const\_get for that module:

module M  
class C  
end  
end

M.const\_get(‘C’).new

I hope this helps

Stefano

---

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 7, 2008, 4:25pm UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/3 "2008-03-07T16:25:46Z")

</div>

On Fri, 07 Mar 2008 08:59:50 -0600, coigner wrote:

> Asking for ideas here but let me preface…

What a helpful group, you answered my question before you even read it!

Found a solution in another message and am thinking “how did I manage to  
overlook that?”

Still would welcome comments and suggestions though. There’s always more  
to learn. And I’m finding that Ruby is the first actually _fun_ language  
I’ve run into in some years now…

---

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 7, 2008, 5:26pm UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/4 "2008-03-07T17:26:42Z")

</div>

On Fri, 07 Mar 2008 10:11:43 -0500, Stefano C. wrote:

> Alle Friday 07 March 2008, coigner ha scritto:
> 
> > Asking for ideas here but let me preface…

\> If your classes are defined top-level, that's all you need. If they're \> defined inside a module, you need to call const\_get for that module: \> \> module M \> class C \> end \> end \> \> M.const\_get('C').new \> \> I hope this helps

Does and thanks. Though I’d already started getting it to work with  
eval.  
Which do you think is better? Or does it matter?

---

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 7, 2008, 5:49pm UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/5 "2008-03-07T17:49:06Z")

</div>

Alle Friday 07 March 2008, coigner ha scritto:

> > end  
> > end
> > 
> > M.const\_get(‘C’).new
> > 
> > I hope this helps
> 
> Does and thanks. Though I’d already started getting it to work with eval.  
> Which do you think is better? Or does it matter?

I’d use const\_get because it’s a tool made for exactly this task, while  
eval  
is a much broader tool. Besides, const\_get seems also faster:

require ‘benchmark’  
Benchmark.bm(“const\_get”.size) do |b|  
b.report(“const\_get”){1\_000\_000.times{Kernel.const\_get(‘C’)}}  
b.report(“eval”){1\_000\_000.times{eval(‘C’)}}  
end

```
           user system total real

```

const\_get 0.890000 0.040000 0.930000 ( 0.932886)  
eval 3.080000 0.100000 3.180000 ( 3.177851)

Of course, if you have a deeply nested module hyerarchy, eval might be  
easier  
to use. Given this hyerarchy:

module A  
module B  
module C  
module D  
class E  
end  
end  
end  
end  
end

to get the class E, you’d need the string “A:🅱:C::D::E”. You can  
obtain E  
using const\_get with this code:

“A:🅱:C::D::E”.split(’::’).inject(Kernel){|res, i| res.const\_get i}

while using eval you can achieve the same with much less code:

eval “A:🅱:C::D::E”

In this case, eval is also faster:

require ‘benchmark’  
Benchmark.bm(“const\_get”.size) do |b|  
b.report(‘const\_get’){1\_000\_000.times{“A:🅱:C::D::E”.split(’::’).inject(  
Kernel){|res, i| res.const\_get i}}}  
b.report(‘eval’){1\_000\_000.times{eval “A:🅱:C::D::E”}}  
end

```
           user system total real

```

const\_get 15.360000 0.940000 16.300000 ( 16.299995)  
eval 5.270000 0.130000 5.400000 ( 5.394793)

Stefano

---

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 8, 2008, 12:18am UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/6 "2008-03-08T00:18:09Z")

</div>

Hi,

On Sat, Mar 8, 2008 at 3:24 AM, coigner [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Does and thanks. Though I’d already started getting it to work with eval.  
> Which do you think is better? Or does it matter?

I think const\_get - in general, though not always - is better. It’s a  
very  
broad tool, and doesn’t convey your intentions correctly. It also means  
that  
if – somehow – some unsafe input ends up in eval, a malicious user  
could  
put whatever they want and have the code executed (e.g.  
“File.unlink(‘/\*’)”  
…), whereas there’s not so much a threat with const\_get.

Arlen

---

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 8, 2008, 6:13am UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/7 "2008-03-08T06:13:29Z")

</div>

> Though I’d already started getting it to work with eval.  
> Which do you think is better? Or does it matter?

Personally I am not one of those that constantly screams “eval is evil”.  
Eval has use cases.

In this scenario though, const\_get is a lot better than eval IMO.  
It does exactly what you need here, no need to add more complexity  
by eval-ing statements - evals tend to be less readable normally too. 🙂

By the way, i think a hierarchy like “A:🅱:C::D::E” looks rather  
contrived.  
In practice I even find it hard to see “A:🅱:C” hierarchy used a lot,  
at least  
at the code parts I had a look at. Normally I see only one Module, and  
inside it a few other classes (sometimes modules, and then a class  
inside too,  
but that is quite rare)

---

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 8, 2008, 1:11am UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/8 "2008-03-08T01:11:35Z")

</div>

With #eval, you are kind of opening Pandora’s box in an interesting  
way. If your code is “open”, you’ve just allowed somebody without  
knowledge to “shoot themselves in the foot”. #eval is definitely  
power that should be used responsibly; a loaded gun that should be  
kept away from software children (such as myself 🙂

Todd

---

<div class="post-metadata">

**Author:** ![coigner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5e9695/32.png) [@coigner](https://www.ruby-forum.com/u/coigner)\
**Post date:** [March 8, 2008, 6:27pm UTC](https://www.ruby-forum.com/t/dynamic-class-thingies-okay-not-sure-how-to-title-this-one/131275/9 "2008-03-08T18:27:05Z")

</div>

On Fri, 07 Mar 2008 18:17:13 -0500, Arlen C. wrote:

> I think const\_get - in general, though not always - is better. It’s a  
> very broad tool, and doesn’t convey your intentions correctly. It also  
> means that if – somehow – some unsafe input ends up in eval, a  
> malicious user could put whatever they want and have the code executed  
> (e.g. “File.unlink(’/\*’)” …), whereas there’s not so much a threat with  
> const\_get.

That’s not so much a problem in this case as the code in question is all  
“behind the scenes” and doesn’t deal with user input. In fact, it’s all  
meant to be “back end” stuff that users don’t deal with directly.

But now that you mention it, I do need to put on the “to do” list that I  
should go over the way the SQL is handled. That would be the weakest  
point in what I’m doing though the actual SQL is already pretty  
isolated.  
There isn’t any “pass me a SQL string and I’ll use it blindly” going on.