ruby里面嵌入C代码

这个问题我以前见人在列表上提过，不过好像没什么明确说法。

我想首先动态语言中的依赖代价要小于静态语言，因为没有编译的步骤。

其次如你所说AR大量使用mix-in和open class，屏蔽了比如new，session这样具体的依赖代码。

再者假如我们在Rails里实现POJO＋DAO，按照AR传统，POJO的getter/setter最好都反射数据库表字段，这样DAO该怎么用呢？否则全都要自己写getter/setter群众肯定不干。既然只用AR，那利用POJO把domain object中的依赖转移到DAO中去又有什么明显好处呢？

最后如果这样分割domain object和DAO的话，那些既更改AR（甚至更改数据库表）又往domain object中插很多新方法的诸多acts_as_xxx神奇功能就很难实现了。这种东西一句话就产生大量依赖，太可怕了，该怎么办呢？。。。算了还是只管杀不管埋吧

关于依赖。我是这么划分的。
一种是 Static Method, 属于 DAO, 或者 Business Layer。比如，create, find, delete_all, transaction 等methods.
一种是 Instance Method, 属于 Domain Object 的。比如, save, delete, destroy 等 methods.

DAO, 或者 Business Layer 的 Static Method 依赖问题不大。static method 放在哪里都一样，随时都可以分离出去，放到别的class or layer中。
用户可以自己做这个工作，Active Record 没有限制。
DAO部分是必须要依赖框架的。Business Layer如果处理Transaction，可以采用AOP, declarative 方式来避免依赖。

依赖问题主要存在属于 Domain Object 的 Instance method。instance method 必须要包括在 Domain Object的定义中，很难分离出来。倒是可以用一个batch mixin task, 把所有的domain object都enhance一遍，让它们都继承ActiveRecord:base。

其实，从实现上来看，save, delete, 这些method很少有多态的需求。没有必要存在为 instance method。save(object), delete(object) 这样的写法也可以，只是看起来没有那么OO。但是这样，就免除了继承ActiveRecord:base的需要。

--------------

这个act_as是第一次听说。ror book 和 active record document 都没有提到。网上能够搜索到的内容很少。

http://textsnippets.com/posts/show/384

好像是加入AOP功能的。不过，没看出来，具体是截获 ActiveRecord:base 的哪个方法。the save method ?
如果是这样，AOP interceptor part 更应该独立于类体系之外而存在了。

Rails最吸引眼球的什么时候成了scaffoldding了

回帖的时候那个飘动的“专业整形”是啥？莫非又是我眼花？

晕了，真是空对空啊
http://wiki.rubyonrails.org/rails/pages/Plugins
acts_as_tree
acts_as_list
acts_as_taggable
acts_as_commentable...

问个问题，哪位对ruby的源代码保护有好的办法的？

如果没有scaffoldding, 那个X分钟搞定一切的视频肯定挂了(光敲键盘就敲死Y的)，没有这个X分钟搞定一切的视频，肯定吸引不了ruby社区之外的眼球.
至少我看完整个视频，只记得这个东西了. hehe

这充分说明了你对RoR完全不了解，那些个其他语言做的rails仿制品的scaffolding个个都比rails的scaffold的界面华丽，可这有什么用？rails scaffold就是一个toy，只有rails门外汉才拿scaffold当个宝。

thanks.  原来叫做 acts as,  plugin。
plugin 就类似于 aop interceptor 的作用。
不过这些 interceptor 的作用不是截获现有的方法，而是mixin 加入更多的方法。

比如，tag support,
http://dev.rubyonrails.com/svn/rails/plugins/acts_as_taggable/lib/acts_as_taggable.rb

module ActiveRecord
  module Acts #:nodoc:
    module Taggable #:nodoc:
      def self.included(base);
        base.extend(ClassMethods);  
      end
      
      module ClassMethods
        def acts_as_taggable(options = {});
          write_inheritable_attribute(:acts_as_taggable_options, {
            :taggable_type => ActiveRecord::Base.send(:class_name_of_active_record_descendant, self);.to_s,
            :from => options[:from]
          });
          
          class_inheritable_reader :acts_as_taggable_options

          has_many :taggings, :as => :taggable, :dependent => true
          has_many :tags, :through => :taggings

          include ActiveRecord::Acts::Taggable::InstanceMethods
          extend ActiveRecord::Acts::Taggable::SingletonMethods          
        end
      end
      
      module SingletonMethods
        def find_tagged_with(list);
          find_by_sql([
            "SELECT #{table_name}.* FROM #{table_name}, tags, taggings " +
            "WHERE #{table_name}.#{primary_key} = taggings.taggable_id " +
            "AND taggings.taggable_type = ? " +
            "AND taggings.tag_id = tags.id AND tags.name IN (?);",
            acts_as_taggable_options[:taggable_type], list
          ]);
        end
      end
      
      module InstanceMethods
        def tag_with(list);
          Tag.transaction do
            taggings.destroy_all

            Tag.parse(list);.each do |name|
              if acts_as_taggable_options[:from]
                send(acts_as_taggable_options[:from]);.tags.find_or_create_by_name(name);.on(self);
              else
                Tag.find_or_create_by_name(name);.on(self);
              end
            end
          end
        end

        def tag_list
          tags.collect { |tag| tag.name.include?(" "); ? "'#{tag.name}'" : tag.name }.join(" ");
        end
      end
    end
  end
end

这里的SingletonMethod就对应Java的 Static Method。但是，ruby的Singleton method是可以被继承和覆盖(override)的。

这段代码就是给某个 Domain Class 加入 find_tagged_with 这个 singleton method.
并给这 Domain Class 的所有 instance 加入 tag_with 这个instance method。

至少对于sington method部分来说，叫做declarative interceptor可能更准确，因为这些mixin 只为每个class执行一次。
这就是T1提到的可能的declare 顺序问题出现的地方吧。

如果有可能，截获现有的method name 来增加更丰富的行为，比用mixin增加更多的 method，更加干净清楚。
这样能够保证更加统一的interface, 更加一致的interface, 能够得到更好的流程控制、算法重用的AOP能力。


把更多的行为，以更多的method的方式，mixin到class method and instance method。
虽然，调用起来更加OO。比如 product.tag_with,  Product.find_tagged_with。
但是从程序流程的控制入口来考虑，这些行为也太分散了。随着act as plugin的个数越来越多，class & instance 的接口宽度越来越宽，method越来越多。
这并不是一个好的AOP实践。当然，也许plugin 并不采用 AOP的概念。

是啊。
应该有代码混淆器之类。
或者源文件加密，interpreter 转载的时候，进行解密的方法。只有特定的 interpreter，才能够解密源代码文件。

听说有一种透明加密技术，是截获文件read/write API的。


这样的思路，应用在 interpreter中，应该可以解决解密性能问题。

这不是什么AOP吧？无非就是通过rails plugin机制往基类里加了几个方法，比如acts_as_taggable，如果你调用这个acts_as_taggable，它就给你的类里面添加几个类方法和实例方法...
看不懂你这一大堆，还是一句话，自己去用，去感受...