[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

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

coigner

3/7/2008 3:00:00 PM

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>
8 Answers

Stefano Crocco

3/7/2008 3:12:00 PM

0

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

3/7/2008 3:23:00 PM

0

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

3/7/2008 4:23:00 PM

0

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

> Alle Friday 07 March 2008, coigner ha scritto:
>> Asking for ideas here but let me preface...
>>
<snip my long winded stuff>
>
> 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

3/7/2008 4:48:00 PM

0

Alle Friday 07 March 2008, coigner ha scritto:
> On Fri, 07 Mar 2008 10:11:43 -0500, Stefano Crocco wrote:
> > Alle Friday 07 March 2008, coigner ha scritto:
> >> Asking for ideas here but let me preface...
>
> <snip my long winded stuff>
>
> > 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?

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

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

Arlen Cuss

3/7/2008 11:17:00 PM

0

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

Hi,

On Sat, Mar 8, 2008 at 3:24 AM, coigner <coignerATgmail@spammers.fry> 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

Todd Benson

3/8/2008 12:11:00 AM

0

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

3/8/2008 5:13:00 AM

0

> 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::D::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)
--
Posted via http://www.ruby-....

coigner

3/8/2008 5:15:00 PM

0

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

> [Note: parts of this message were removed to make it a legal post.]
>
> Hi,
>
> On Sat, Mar 8, 2008 at 3:24 AM, coigner <coignerATgmail@spammers.fry>
> 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.

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.