#10963: More functorial constructions
-------------------------------------+-------------------------------------
       Reporter:  nthiery            |        Owner:  stumpc5
           Type:  enhancement        |       Status:  needs_info
       Priority:  major              |    Milestone:  sage-6.2
      Component:  categories         |   Resolution:
       Keywords:  days54             |    Merged in:
        Authors:  Nicolas M. Thiéry  |    Reviewers:  Simon King, Frédéric
Report Upstream:  N/A                |  Chapoton
         Branch:                     |  Work issues:
  public/ticket/10963-doc-           |       Commit:
  distributive                       |  7ab3103368e46d33f37e135a9eb09a1e16a029a7
   Dependencies:  #11224, #8327,     |     Stopgaps:
  #10193, #12895, #14516, #14722,    |
  #13589, #14471, #15069, #15094,    |
  #11688, #13394, #15150, #15506,    |
  #15757, #15759                     |
-------------------------------------+-------------------------------------

Comment (by vbraun):

 Replying to [comment:543 nthiery]:
 > Then it's natural to follow the usual OO paradigm where, when something
 in the hierarchy attaches a semantic to a name (e.g. by declaring a method
 with that name), the subthings in the hierarchy can implement that
 semantic by reusing the same name

 That is one piece of OO. But it is not the "usual OO paradigm" unless you
 also have encapsulation, that is, unrelated "things" being independent (in
 particular, sub-things of independent things being independent). Reusing
 (really: overriding) a name is supposed to replace one implementation with
 another, but the original and the replacement are still independent.
 Really, what you propose is more like a single flat namespace where each
 axiom is a global name. And that is not OOP.

 > [...]Now, I'd
 > appreciate if you would acknowledge the efforts I put in writing this
 > documentation, and use it as a basis for a constructive discussion.

 I certainly do acknowledge and appreciate your effort. But when it comes
 to reviewing I am supposed to be an advocate of other users, not of the
 author. And I think there is too much implicit magic and not enough syntax
 to explicitly tie together the axiom implementations. Which will hurt
 other users/developers when they first encounter the category code. Just
 documenting that axioms are implicit magic is IMHO not good enough when
 you can just make their relationship explicit.

--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:545>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to