I am writing the AS core extensions guide, and would like to know your opinion about Class#subclasses: AS defines Class#subclasses, it returns the name of all descendants (strings). Same as AC::Base.subclasses. AR::Base.subclasses on the other hand returns all descendants (classes), and it is protected. The guide could warn about AR::Base. We could also redefine AR::Base.subclasses to match the rest (I''d volunteer). ack says there are not a lot of occurrences, but it wouldn''t be backwards compatible. What do you think? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Sat, Jan 16, 2010 at 12:37, Xavier Noria <fxn@hashref.com> wrote:> > The guide could warn about AR::Base. We could also redefine > AR::Base.subclasses to match the rest (I''d volunteer). ack says there > are not a lot of occurrences, but it wouldn''t be backwards compatible.I can imagine that plugins might use Base.subclasses to iterate over AR models. thinking-sphinx does this, for instance. The question is, why would we standardize on strings? Why not actual references, like `ancestors`? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Sat, Jan 16, 2010 at 12:56 PM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On Sat, Jan 16, 2010 at 12:37, Xavier Noria <fxn@hashref.com> wrote: >> >> The guide could warn about AR::Base. We could also redefine >> AR::Base.subclasses to match the rest (I''d volunteer). ack says there >> are not a lot of occurrences, but it wouldn''t be backwards compatible. > > I can imagine that plugins might use Base.subclasses to iterate over AR > models. > thinking-sphinx does this, for instance. > > The question is, why would we standardize on strings? Why not actual > references, like `ancestors`?I first thought about changing AR because at least that is a protected method and it could be the case that it breaks less code. But all being equal, I''d expect subclasses to return class objects indeed, for example Object#subclasses_of does, and anyway that is what the name would suggest to me. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Sat, Jan 16, 2010 at 12:37 PM, Xavier Noria <fxn@hashref.com> wrote:> AS defines Class#subclasses, it returns the name of all descendants > (strings). Same as AC::Base.subclasses.Ah, but they are not equivalent because AC::Base#subclasses includes names of non-reachable class objects, whereas Class#subclasses filters them out. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> Ah, but they are not equivalent because AC::Base#subclasses includes > names of non-reachable class objects, whereas Class#subclasses filters > them out.This difference is probably just to enable reset_subclasses to work around the ruby memory-leak discussed at length on: http://rails.lighthouseapp.com/projects/8994/tickets/1339-arbase-should-not-be-nuking-its-children-just-because-it-lost-interest There''s no reason that the AR version can''t be called something else and move subclasses to be the same everywhere. -- Cheers Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Sun, Jan 17, 2010 at 1:54 AM, Michael Koziarski <michael@koziarski.com> wrote:>> Ah, but they are not equivalent because AC::Base#subclasses includes >> names of non-reachable class objects, whereas Class#subclasses filters >> them out. > > This difference is probably just to enable reset_subclasses to work > around the ruby memory-leak discussed at length on: > > http://rails.lighthouseapp.com/projects/8994/tickets/1339-arbase-should-not-be-nuking-its-children-just-because-it-lost-interest > > There''s no reason that the AR version can''t be called something else > and move subclasses to be the same everywhere.I''ve seen that the classes in the framework that need #subclasses implement their own version using the inherited hook. It turns out that Class#subclasses was not being used in the framework, Jeremy suggested it shouldn''t be a core extension in that case and we''ve removed it. That in turn unrolled a series of related utilities that were unused, they are: Object#subclasses_of Object#remove_subclasses_of Object#extended_by Object#extend_with_included_modules_from Class#remove_subclasses Class#remove_class Class#reachable? Class#descedents They are gone as well, and I''ll prepare a patch to deprecate them for 2.3. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Jan 27, 2010 at 08:44, Xavier Noria <fxn@hashref.com> wrote:> That in turn unrolled a series of related utilities that were unused, they > are: > > Object#subclasses_of > Object#remove_subclasses_of > Object#extended_by > Object#extend_with_included_modules_from > Class#remove_subclasses > Class#remove_class > Class#reachable? > Class#descedents > > They are gone as well, and I''ll prepare a patch to deprecate them for 2.3.Looks like remnants of the old reloading system? So, if some classes (like ActiveRecord) in the framework implement their own `subclasses`, why not implement it once in AS and remove those other implementations? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, Jan 27, 2010 at 9:26 AM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> Looks like remnants of the old reloading system? > So, if some classes (like ActiveRecord) in the framework implement their own > `subclasses`, why not implement it once in AS and remove those other > implementations?Sounds good because there are 4 o 5 of them. I think they are equivalent except perhaps for visibility which is not probably big deal if we uniform this. I''ll have a look at it. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.