Andreas/evennia
1
0
Fork 0
mirror of https://github.com/evennia/evennia.git synced 2026-03-26 09:46:32 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Updated HTML docs

Browse source
This commit is contained in:
Griatch 2020-06-16 22:49:43 +02:00
parent f505351730
commit a551188691
1002 changed files with 30387 additions and 9820 deletions
Download patch file Download diff file Expand all files Collapse all files

40
docs/1.0-dev/API-refactoring.html
View file

@ -7,11 +7,13 @@
<title>API refactoring &#8212; Evennia 1.0-dev documentation</title>
<link rel="stylesheet" href="_static/nature.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<script id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></script>
<script src="_static/jquery.js"></script>
<script src="_static/underscore.js"></script>
<script src="_static/doctools.js"></script>
<script src="_static/language_data.js"></script>
<link rel="shortcut icon" href="_static/favicon.ico"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
@ -25,7 +27,10 @@
<li class="right" >
<a href="py-modindex.html" title="Python Module Index"
>modules</a> |</li>
<li class="nav-item nav-item-0"><a href="index.html">Evennia 1.0-dev documentation</a> &#187;</li>
<li class="nav-item nav-item-0"><a href="index.html">Evennia 1.0-dev documentation</a> &#187;</li>
<li class="nav-item nav-item-last"><a href="#">API refactoring</a></li>
</ul>
</div>
@ -36,17 +41,30 @@
<div class="section" id="api-refactoring">
<h1>API refactoring<a class="headerlink" href="#api-refactoring" title="Permalink to this headline"></a></h1>
<p>Building up to Evennia 1.0 and beyond, it’s time to comb through the Evennia API for old cruft. This whitepage is for anyone interested to contribute with their views on what part of the API needs refactoring, cleanup or clarification (or extension!)</p>
<p>Note that this is not a forum. To keep things clean, each opinion text should ideally present a clear argument or lay out a suggestion. Asking for clarification and any side-discussions should be held in chat or forum.</p>
<p>Building up to Evennia 1.0 and beyond, it’s time to comb through the Evennia API for old cruft. This
whitepage is for anyone interested to contribute with their views on what part of the API needs
refactoring, cleanup or clarification (or extension!)</p>
<p>Note that this is not a forum. To keep things clean, each opinion text should ideally present a
clear argument or lay out a suggestion. Asking for clarification and any side-discussions should be
held in chat or forum.</p>
<hr class="docutils" />
<div class="section" id="griatch-aug-13-2019">
<h2>Griatch (Aug 13, 2019)<a class="headerlink" href="#griatch-aug-13-2019" title="Permalink to this headline"></a></h2>
<p>This is how to enter an opinion. Use any markdown needed but stay within your section. Also remember to copy your text to the clipboard before saving since if someone else edited the wiki in the meantime you’ll have to start over.</p>
<p>This is how to enter an opinion. Use any markdown needed but stay within your section. Also remember
to copy your text to the clipboard before saving since if someone else edited the wiki in the
meantime you’ll have to start over.</p>
</div>
<div class="section" id="griatch-sept-2-2019">
<h2>Griatch (Sept 2, 2019)<a class="headerlink" href="#griatch-sept-2-2019" title="Permalink to this headline"></a></h2>
<p>I don’t agree with removing explicit keywords as suggested by <a class="reference external" href="/API-refactoring.html#reduce-usage-of-optionalpositional-arguments-aug-29-2019">Johnny on Aug 29 below</a>. Overriding such a method can still be done by <code class="docutils literal notranslate"><span class="pre">get(self,</span> <span class="pre">**kwargs)</span></code> if so desired, making the kwargs explicit helps IMO readability of the API. If just giving a generic <code class="docutils literal notranslate"><span class="pre">**kwargs</span></code>, one must read the docstring or even the code to see which keywords are valid.</p>
<p>On the other hand, I think it makes sense to as a standard offer an extra <code class="docutils literal notranslate"><span class="pre">**kwargs</span></code> at the end of arg-lists for common methods that are expected to be over-ridden. This make the API more flexible by hinting to the dev that they could expand their own over-ridden implementation with their own keyword arguments if so desired.</p>
<p>I don’t agree with removing explicit keywords as suggested by [Johnny on Aug 29 below](API-
refactoring#reduce-usage-of-optionalpositional-arguments-aug-29-2019). Overriding such a method can
still be done by <code class="docutils literal notranslate"><span class="pre">get(self,</span> <span class="pre">**kwargs)</span></code> if so desired, making the kwargs explicit helps IMO
readability of the API. If just giving a generic <code class="docutils literal notranslate"><span class="pre">**kwargs</span></code>, one must read the docstring or even the
code to see which keywords are valid.</p>
<p>On the other hand, I think it makes sense to as a standard offer an extra <code class="docutils literal notranslate"><span class="pre">**kwargs</span></code> at the end of
arg-lists for common methods that are expected to be over-ridden. This make the API more flexible by
hinting to the dev that they could expand their own over-ridden implementation with their own
keyword arguments if so desired.</p>
</div>
<hr class="docutils" />
<div class="section" id="johnny">
@ -59,7 +77,10 @@
<span class="n">default_access</span><span class="o">=</span><span class="kc">True</span><span class="p">,</span> <span class="n">return_list</span><span class="o">=</span><span class="kc">False</span><span class="p">):</span>
</pre></div>
</div>
<p>Many classes have methods requiring lengthy positional argument lists, which are tedious and error-prone to extend and override especially in cases where not all arguments are even required. It would be useful if arguments were reserved for required inputs and anything else relegated to kwargs for easier passthrough on extension.</p>
<p>Many classes have methods requiring lengthy positional argument lists, which are tedious and error-
prone to extend and override especially in cases where not all arguments are even required. It would
be useful if arguments were reserved for required inputs and anything else relegated to kwargs for
easier passthrough on extension.</p>
</div>
</div>
</div>
@ -122,7 +143,10 @@
<li class="right" >
<a href="py-modindex.html" title="Python Module Index"
>modules</a> |</li>
<li class="nav-item nav-item-0"><a href="index.html">Evennia 1.0-dev documentation</a> &#187;</li>
<li class="nav-item nav-item-0"><a href="index.html">Evennia 1.0-dev documentation</a> &#187;</li>
<li class="nav-item nav-item-last"><a href="#">API refactoring</a></li>
</ul>
</div>
<div class="footer" role="contentinfo">