1. 17 Feb, 2013 1 commit
  2. 09 Dec, 2012 1 commit
  3. 18 Mar, 2012 1 commit
  4. 23 Jan, 2010 1 commit
  5. 20 Jan, 2010 1 commit
  6. 30 Nov, 2009 2 commits
  7. 21 Nov, 2009 1 commit
    • Pascal Costanza's avatar
      Major reorganization of the code, plus support for generic function invocation... · 489aba97
      Pascal Costanza authored
      Major reorganization of the code, plus support for generic function invocation protocols in Allegro Common Lisp.
      Ignore-this: 9be21704dcdc2ab8e47f596e5a82ff3b
      A major reorganization of the code became necessary, because the old structure became harder than necessary to maintain. I have now moved code that is similar across many Common Lisp implementations into a shared source code file, and leave only small parts to implementation-dependent source code files. The setup of packages is combined into one file, and all relevant symbols are now exported from the packages, including symbols that may not have any definitions in some Common Lisp implementations. To further simplify things, I have moved source code from subfolders into the main folder, to avoid hierarchy creep.
      Finally, Allegro Common Lisp now also supports the full generic function invocation protocols.
  8. 17 Nov, 2009 1 commit
    • Pascal Costanza's avatar
      Separated code strictly into folders per implementation, and cleaned up the code. · 198ec387
      Pascal Costanza authored
      Ignore-this: 8505094d361aee4763045939771f8cfa
      Originally, when I started Closer to MOP, I expected implementations that stem from the same original implementations to have similar issues with regard to CLOS MOP compatibility. So specifically, I packaged the code for CMUCL and SBCL into one folder, and that for MCL, OpenMCL and Clozure Common Lisp into one folder. It turned out that the incompatibilites are not at all similar, and that this created more problems than it solved. So I now decided to keep implementations strictly separated, to make my life easier in the future.
  9. 04 Nov, 2009 1 commit
  10. 02 Nov, 2009 4 commits
  11. 06 Nov, 2008 1 commit
    • Pascal Costanza's avatar
      Added utility function subclassp. · a641d0f0
      Pascal Costanza authored
      Some CLOS implementations have problems with determining subtype relationships between classes in certain corner cases. For example, clisp doesn't like to determine such relationships for forward referenced classes, and some instances of PCL have problems with anonymous classes under certain circumstances (primarily when doing CLOS MOP programming).
      Apparently, subtypep is typically implemented based on the class precedence list, which can only be determined until after a class has been finalized, and this seems to be one of the reasons for these problems. However, the CLOS MOP places restrictions on methods for compute-class-precedence-list such that the subtype relationship actually does _not_ depend on the precedence list, but can be based on a membership test in the unordered set of all direct and indirect superclasses.
      I have provided subclassp in Closer to MOP as a utility function that does just that: It walks the superclass hierarchy to determine whether one class is a subclass of another. This implementation is not that efficient, so it should only be used when subtypep fails. (It could probably be made more efficient, but since this is only provided as a replacement for subtypep in hopefully rare corner cases, I haven't put the energy into this to do this yet.)
  12. 05 Nov, 2008 1 commit
  13. 29 May, 2008 1 commit
  14. 14 Oct, 2006 1 commit
  15. 20 Jul, 2006 1 commit
    • Pascal Costanza's avatar
      Added a new utility function ensure-finalized. · 347d934e
      Pascal Costanza authored
      A pretty common idiom is this:
      (unless (class-finalized-p class)
        (finalize-inheritance class))
      This is captured in the new utility function ensure-finalized.
  16. 27 Jan, 2006 1 commit
  17. 02 Aug, 2005 1 commit