[Nitro] [OG] eval and style
transfire at gmail.com
transfire at gmail.com
Wed Jan 31 20:08:33 EST 2007
On Jan 31, 5:35 pm, "nya... at gmail.com" <nya... at gmail.com> wrote:
> Having just done a darcs get of the repo, I'm realizing that my
> initial need to submit patches has already been fixed by moving the
> attr_* methods to ann_attr in facets (which, incidentally is eval'ing
> strings to extend classes...)
yes, but that's one fine, it's just to reiterate the same bit of code
for attr _writer, _reader and _accessor. one could get do it
otherwise, but it's actually more beneficial to str eval in this case.
indeed, there are places where str evals work best.
> I'd been willing to make some of these changes as I run across them.
> The current big one I see is in og/store/sql.rb where:
>
> ... klass.module_eval %{
> def og_insert(store)
> #{insert_advices :pre, :og_insert, klass, :advices}
> #{insert_sql sql, klass}
> #{insert_advices :post, :og_insert, klass, :advices}
> end
> }
> end
>
> # The insert sql statements.
>
> def insert_sql(sql, klass)
> %{
> store.exec "#{sql}"
> @#{klass.primary_key} = store.last_insert_id
> }
> end
>
> should probably become something like
>
> klass.instance_eval do
> def og_insert(store)
> #replace insert_advices :pre, :og_insert, klass, :advices
> store.exec sql
> @primary_key = store.last_insert_id
> #replace insert_advices :post, :og_insert, klass, :advices
> end
> end
>
> Or, as Trans was suggesting, a module inclusion to minimize the
> dynamic code. A pleasant side benefit would be that og_insert would
> suddenly have rdoc!
Yep. That is a good example of where it would be best to get rid of
the eval (and direct injection of code into the class) But like I said
it's not always so easy. If you have some time, please give it some
effort. That would be great.
T.
More information about the Nitro-general
mailing list