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

[coigner]

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. <g>

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 <g>) 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. <G>

 

[Stefano Crocco]

Alle Friday 07 March 2008, coigner ha scritto:

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. <g>

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 <g>) 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. <G>

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

 

[coigner]

Asking for ideas here but let me preface...

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

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...

 

[coigner]

Alle Friday 07 March 2008, coigner ha scritto:

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

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

 

[Stefano Crocco]

Alle Friday 07 March 2008, coigner ha scritto:

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::B::C:::E". You can obtain E
using const_get with this code:

"A::B::C:::E".split('::').inject(Kernel){|res, i| res.const_get i}

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

eval "A::B::C:::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::B::C:::E".split('::').inject(
Kernel){|res, i| res.const_get i}}}
b.report('eval'){1_000_000.times{eval "A::B::C:::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

 

[Arlen Cuss]

[Note: parts of this message were removed to make it a legal post.]

Hi,

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

 

[Todd Benson]

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

 

[Marc Heiler]

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::B::C:::E" looks rather
contrived.
In practice I even find it hard to see "A::B::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)

 

[coigner]

[Note: parts of this message were removed to make it a legal post.]

Hi,

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.

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.