csh
/
y.st.
fork de y.st./y.st.


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142
							<?xml version="1.0" encoding="utf-8"?>
<!--
                                                                                     
 h       t     t                ::       /     /                     t             / 
 h       t     t                ::      //    //                     t            // 
 h     ttttt ttttt ppppp sssss         //    //  y   y       sssss ttttt         //  
 hhhh    t     t   p   p s            //    //   y   y       s       t          //   
 h  hh   t     t   ppppp sssss       //    //    yyyyy       sssss   t         //    
 h   h   t     t   p         s  ::   /     /         y  ..       s   t    ..   /     
 h   h   t     t   p     sssss  ::   /     /     yyyyy  ..   sssss   t    ..   /     
                                                                                     
	<https://y.st./>
	Copyright © 2016 Alex Yst <mailto:copyright@y.st>

	This program is free software: you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation, either version 3 of the License, or
	(at your option) any later version.

	This program is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with this program. If not, see <https://www.gnu.org./licenses/>.
-->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<base href="https://y.st./en/weblog/2016/11-November/07.xhtml" />
		<title>Coding standards &lt;https://y.st./en/weblog/2016/11-November/07.xhtml&gt;</title>
		<link rel="icon" type="image/png" href="/link/CC_BY-SA_4.0/y.st./icon.png" />
		<link rel="stylesheet" type="text/css" href="/link/basic.css" />
		<link rel="stylesheet" type="text/css" href="/link/site-specific.css" />
		<script type="text/javascript" src="/script/javascript.js" />
		<meta name="viewport" content="width=device-width" />
	</head>
	<body>
		<nav>
			<p>
				<a href="/en/">Home</a> |
				<a href="/en/a/about.xhtml">About</a> |
				<a href="/en/a/contact.xhtml">Contact</a> |
				<a href="/a/canary.txt">Canary</a> |
				<a href="/en/URI_research/"><abbr title="Uniform Resource Identifier">URI</abbr> research</a> |
				<a href="/en/opinion/">Opinions</a> |
				<a href="/en/coursework/">Coursework</a> |
				<a href="/en/law/">Law</a> |
				<a href="/en/a/links.xhtml">Links</a> |
				<a href="/en/weblog/2016/11-November/07.xhtml.asc">{this page}.asc</a>
			</p>
			<hr/>
			<p>
				Weblog index:
				<a href="/en/weblog/"><abbr title="American Standard Code for Information Interchange">ASCII</abbr> calendars</a> |
				<a href="/en/weblog/index_ol_ascending.xhtml">Ascending list</a> |
				<a href="/en/weblog/index_ol_descending.xhtml">Descending list</a>
			</p>
			<hr/>
			<p>
				Jump to entry:
				<a href="/en/weblog/2015/03-March/07.xhtml">&lt;&lt;First</a>
				<a rel="prev" href="/en/weblog/2016/11-November/06.xhtml">&lt;Previous</a>
				<a rel="next" href="/en/weblog/2016/11-November/08.xhtml">Next&gt;</a>
				<a href="/en/weblog/latest.xhtml">Latest&gt;&gt;</a>
			</p>
			<hr/>
		</nav>
		<header>
			<h1>Coding standards</h1>
			<p>Day 00611: Monday, 2016 November 07</p>
		</header>
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2016/11/07.jpg" alt="White flowers and pink buds" class="weblog-header-image" width="811" height="480" />
<p>
	Current countdowns:
</p>
<ul>
	<li>234 scheme-specific <abbr title="Uniform Resource Identifier">URI</abbr>-parsing classes to write and add to <a href="https://git.vola7ileiax4ueow.onion/y.st./include.d/releases">include.d</a></li>
	<li>1 free elective left in my associate degree program</li>
	<li>4 free electives left in my bachelor degree program</li>
</ul>
<p>
	Topics for essays that I want to write outside of school:
</p>
<ul>
<li>How the <abbr title="GNU &quot;Free&quot; Documentation License">GFDL</abbr> isn&apos;t a free license, and is effectively nonfree even when invariant sections aren&apos;t used</li>
<li>How the telephone number system is screwy</li>
<li>How postpaid mobile plans are bad for customers</li>
<li>How connections using &quot;untrusted&quot; <abbr title="Transport Layer Security">TLS</abbr> certificates are more trustworthy than connections without any <abbr title="Transport Layer Security">TLS</abbr> certificate at all</li>
<li>The importance of free software</li>
<li>The importance of free media</li>
</ul>
<p>
	I spoke with the author of that article on <a href="https://ocramius.github.io./blog/accessing-private-php-class-members-without-reflection/">bypassing the <code>private</code> key word in <abbr title="PHP: Hypertext Preprocessor">PHP</abbr></a>, and it seems that while they approve of this ability to render the <code>private</code> key word ineffective, they only approve of doing this from within libraries and tools.
	They don&apos;t think that it should be used from the main code of a project.
	I don&apos;t think that closures belong in libraries and tools though, but in the main project.
	From within a library, regular, named functions and methods should be used.
	The only place that I&apos;d ever use closures is in non-library code.
	After all, closures are class instances, which makes them variables, not functions.
	With that in mind, our opinions on the usage of closures is incompatible.
	However, it doesn&apos;t detract from the real issue.
	When developers mark a property (or method) as private, they do so for a reason.
	The author said that the code used for object serialization shouldn&apos;t be contained within the class definition itself, but in my opinion, it should.
	Serialization is a feature of the objects of a class, so it should be defined by the class itself.
	If it&apos;s necessary to define it separately and not have it as part of the object (so using a parent class with the serialization code isn&apos;t an option because the code would become a part of the object&apos;s definition when the child class inherits it), make the properties protected instead of private.
	Then, have a serializer class extend the class that has the data objects and use static methods in the child class to interact with the protected properties of the parent class.
</p>
<p>
	I finished up my work on the function for finding what parts of include.d to include in a project if trying to avoid dependencies, and have made a new <a href="https://git.vola7ileiax4ueow.onion/y.st./include.d/releases">release</a>.
	Though the point of this release is the new function, I&apos;ve also included my fixes to the main <abbr title="Uniform Resource Identifier">URI</abbr>-handling framework.
	I wanted to wait and release those fixes with the rest of the big <abbr title="Uniform Resource Identifier">URI</abbr> scheme update, but my debug code makes assumptions that aren&apos;t valid for outdated versions of include.d code from before the 0.0.1.4 release.
	Specifically, the debugging code complains about repeated exception codes where the exception codes actually are unique.
	As the <abbr title="Uniform Resource Identifier">URI</abbr>-handling code is being worked on only in another branch, the version in the master branch had stagnated, so the assumptions about how to find the exception codes didn&apos;t apply, confusing the debugging code.
	I don&apos;t anticipate further issues with the branched <abbr title="Uniform Resource Identifier">URI</abbr>-handling code though.
	I&apos;ve also removed a couple of exception classes that, had I read the description of their parent classes correctly, I would never have included in include.d anyway.
</p>
<p>
	I spent a chunk of the day looking for boxes of things that can be stashed in the storage unit, but it&apos;s not my stuff so I have no idea what needs to be kept accessible and what can be stored for the time being.
	Needless to say, it didn&apos;t go well.
	I also labeled the boxes on the high shelves in the garage though, which should be of some use.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
		<hr/>
		<p>
			Copyright © 2016 Alex Yst;
			You may modify and/or redistribute this document under the terms of the <a rel="license" href="/license/gpl-3.0-standalone.xhtml"><abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="General Public License version Three or later">GPLv3+</abbr></a>.
			If for some reason you would prefer to modify and/or distribute this document under other free copyleft terms, please ask me via email.
			My address is in the source comments near the top of this document.
			This license also applies to embedded content such as images.
			For more information on that, see <a href="/en/a/licensing.xhtml">licensing</a>.
		</p>
		<p>
			<abbr title="World Wide Web Consortium">W3C</abbr> standards are important.
			This document conforms to the <a href="https://validator.w3.org./nu/?doc=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F11-November%2F07.xhtml"><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> 5.1</a> specification and uses style sheets that conform to the <a href="http://jigsaw.w3.org./css-validator/validator?uri=https%3A%2F%2Fy.st.%2Fen%2Fweblog%2F2016%2F11-November%2F07.xhtml"><abbr title="Cascading Style Sheets">CSS</abbr>3</a> specification.
		</p>
	</body>
</html>