#20859: Simplify the logic handling the EvaluationMethods mixin class for
Expression
-------------------------------------+-------------------------------------
       Reporter:  jdemeyer           |        Owner:
           Type:  enhancement        |       Status:  new
       Priority:  major              |    Milestone:  sage-7.3
      Component:  symbolics          |   Resolution:
       Keywords:                     |    Merged in:
        Authors:  Nicolas M. ThiƩry  |    Reviewers:
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  
u/nthiery/optimize_method_lookup_from_the_categories_for_instances_of_cython_classes|
  5619a7d0f032f4273069166e6babf938b8c3f40a
   Dependencies:  #20825, #20686     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by nthiery):

 Replying to [comment:9 jdemeyer]:
 > Given that it's a `class`, I would expect it to behave like a
 > `class`. If you insist that it should not behave like a `class`,
 > then at least make it explicit and invent a new metaclass
 > `BagOfMethods` which disallows inheritance for example.

 Using a metaclass would mean one more piece of purely technical
 syntax, which is one more chance for the programmer to forget
 something. Still you have a good point here: the infrastructure should
 check that XXXMethods inherits from nothing, and raise an explanatory
 error message if not.

 > How is a random Sage developer supposed to know that? That's one
 > thing that I really don't like about the category framework in
 > general: it makes several assumptions which work fine most of the
 > time, but can bite you badly (the automatic binding is another such
 > one). It almost feels like a slightly different programming language
 > (that `class` is not ''really'' a Python class, it's just a dict).

 That's the problem with every framework: a Django programmer needs to
 learn some about Django, etc, either from example by looking at
 existing code, or by reading the documentation.

 Now does Sage really need such a framework? I am convinced enough
 about it to have invested altogether one solid year of work into
 it. Which does not mean I am not completely wrong :-)

 I also believe in concise syntax with minimal boilerplate. Of course
 the price is additional complexity for those developers like you that
 not only use, but also work on the infrastructure itself.

 Cheers,
                              Nicolas

--
Ticket URL: 
<https://u3351942.ct.sendgrid.net/wf/click?upn=aTs-2BwUSKwq20U-2FVxpZle9V7rZPHNFdCZn9IqCcBPbg6Wx7VTUgJoegiKQ3QL4-2BXvw02VkAHE99KF2HraGXbrwA-3D-3D_gXX0YPkjCa6kfMda2NWALp0MQ-2FOvmULrxPdhd2nGLCaMMjhZiny1s3ZJf4O89vFdDsnNB6YgdFaT-2BTM6P9s3KgzyTFt9C3pyl-2Bv14520-2FBluqUGBWM3hv3PT-2FssVcCzYB3Dce7dJiN1V1n8ooA0wQSzshaAiSeaWk33EGyG-2FjyKIdhOSORlHEZkdYNRDH0-2BL9JxiMJPi6JiP51q8IvmczKXdQoOTuzpSBTucQXbmr4E-3D>
Sage 
<https://u3351942.ct.sendgrid.net/wf/click?upn=jm4cvpnHFskDUI5PLE4HCGcqpDNkng8vhBVTwprYF6Q-3D_gXX0YPkjCa6kfMda2NWALp0MQ-2FOvmULrxPdhd2nGLCaMMjhZiny1s3ZJf4O89vFdDsnNB6YgdFaT-2BTM6P9s3KoxyncSIRTyvENr7ZzGRoxBQJliIpVN6fjMAhTIH1S-2FkCt3t4dWGh6fXguO1oC6paCkSdE8-2Fso3C-2BYgWbIZotxrY5rrKPeySX5Oeq71OtuClQ-2FSAE6MYW35s-2FNNi87zxQEZT-2BodjXggKlBHxQDFk1VA-3D>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to