y.st./source/pages/en/weblog/2016/11-November/28.xhtml

<?php
/**
 * <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/>.
**/

$xhtml = array(
	'title' => 'I learned the secret to protecting values from closures.',
	'body' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2016/11/28.jpg" alt="A gated apartment complex" class="weblog-header-image" width="811" height="480" />
<h2 id="general">General news</h2>
<p>
	After my alarm went off, I must have fallen back asleep.
	It only felt like I continued laying down for a couple of minutes, but the next thing that I knew, more than half an hour had passed.
	I ended up having to skip picking up lunch on my way to work, and I still clocked in five minutes late.
	I made up for it though by staying an extra half hour when the shift leader in charge needed some extra manpower while waiting for the rest of the night crew to arrive.
</p>
<p>
	Professor Shyguy just opened preorders for their new album, <a href="https://professorshyguy.bandcamp.com/album/merry-chipmas-v-2">Merry Chipmas v.2</a>.
	Unlike the original Merry Chipmas, which was labeled as having all rights reserved, this album is covered by the {$a['CC BY 3.0']} license! It appears to have the original five songs from the first album, plus five more.
	Speaking of the first album, it&apos;s gone missing.
	Professor Shyguy has taken it off the market.
	The new album is scheduled to be released on 2016-12-01.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
<h2 id="include.d"><a href="https://git.volatile.ch./y.st./include.d/releases">include.d</a></h2>
<p>
	What if $a[URI] components are stored in a static variable within a method? Is that possible? Would different instances of the class have different values in their static variables? Would closures be able to tamper with this variable? These are the questions that haunted me after I had a sudden flash of inspiration early this morning.
	As far as I can tell, there isn&apos;t a way for closures to tamper with this variable, provided that all of the normalization and validation features are supplied within the method itself.
	However, all instances of the class share a single copy of the variable.
	This can easily be fixed by making the variable an array and finding some way of granting each instance of the class a unique key.
	The key itself doesn&apos;t even need to be protected from closures.
	If closures tamper with the key, two objects will either share the same values or one object will have a bad key.
	I can either set the storage method to recover by assigning a default key or allow such objects to simply be broken.
	As long as no existing data set used by the class contains invalid $a[URI] components, or a combination of valid $a[URI] components that are invalid when used together, everything is awesome.
	Lastly, this tactic completely breaks the <code>\\var_export()</code> function, as <code>\\var_export()</code> won&apos;t see the data any more; after all, it won&apos;t be stored in properties at that point.
	I should probably implement some sort of workaround.
	One possibility would be to put a string copy of the $a[URI] in a property.
	Closures would have access to this and be able to bork it, but that&apos;s about the best that I can do.
</p>
<p>
	The realization of how I might need to fix up my $a[URI] classes once again came right after I finished bringing the <code>\\st\\y\\uri\\gopher</code> class up to speed with my last $a[API] update.
	At first, I was thinking that hopefully not too much of my last $a[API] update will go to waste.
	It&apos;s really a shame that I even have to jump through all these hoops just to keep my $a[API] from being broken.
	Closures should not be allowed to break basic $a[API] features.
	After thinking about his all day though, I came to the conclusion that it simply isn&apos;t worth it to work around this bug.
	Using a static variable containing an array would certainly have the effect that I&apos;m after, however, it breaks cloning and deconstructing features that are built into basic $a[PHP] objects.
	I&apos;d have to do all cloning manually, which would certainly make my code less efficient, and if I failed to implement deconstructing manually, all past object data would be saved even after the objects are deleted.
	On a longer-running script that uses a lot of $a[URI] objects, such as my onion spider, memory would fill up.
	You can&apos;t break my $a[URI] objects accidentally, at least not with this closure feature.
	If you break my $a[URI] objects in your script by using closures on them, you&apos;ve done it with intent to make the code fail.
	As such, I&apos;m just going to leave it alone.
	It&apos;s the problem of whoever causes it, not me.
	Now that I know how to protect variables, I can stop obsessing over this.
</p>
<p>
	I&apos;ve been working on my big $a[URI] update for a while now.
	This update adds all scheme-specific $a[URI] syntaxes to include.d as classes.
	However, this is boring.
	Educational, but very, very boring.
	I&apos;ve decided to attack the problem of scheme-specific $a[URI] syntax in a different way.
	Instead of one big update, I&apos;ll add a few $a[URI] schemes to each update.
	If the update is a 0.0.0.1-level or higher update, I&apos;ll add at least one permanent scheme, at least one historic scheme, and at least one provisional scheme.
	If I don&apos;t have those ready yet, I won&apos;t make a release yet.
	If I <strong>*do*</strong> have them ready though, I can (but do not have to) ignore the $a[URI] code for the time being.
	Updates that are 0.0.0.0.1-level or below updates will be prohibited from introducing new $a[URI] scheme classes.
</p>
<h2 id="apartment">Apartment hunting</h2>
<p>
	I went to the apartment complex at which I filed my initial housing application, and had them update the telephone number that they have on file for me.
	Now if Google does end up revoking the telephone number that they issued me, the damage will be limited.
</p>
END
);