<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Legacy on Murat Useinov</title>
    <link>https://useinov.com/tags/legacy/</link>
    <description>Recent content in Legacy on Murat Useinov</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 10 Oct 2025 21:30:00 +0300</lastBuildDate>
    <atom:link href="https://useinov.com/tags/legacy/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Coding agents meet legacy PHP</title>
      <link>https://useinov.com/posts/2025/agents-and-legacy/</link>
      <pubDate>Fri, 10 Oct 2025 21:30:00 +0300</pubDate>
      <guid>https://useinov.com/posts/2025/agents-and-legacy/</guid>
      <description>&lt;p&gt;A strange-looking condition in a 2015 module, &amp;ldquo;fixed&amp;rdquo; by an agent. All tests green, static analysis clean, and the condition was a business rule with history. My review caught it. Barely.&lt;/p&gt;
&lt;p&gt;That came out of an experiment I ran this month: a coding agent on one legacy PHP module, since agents can do multi-file changes now and every old codebase suddenly looks like a target.&lt;/p&gt;
&lt;p&gt;The setup matters more than the model. I did not ask &amp;ldquo;modernize this&amp;rdquo;. I gave a narrow migration goal on one bounded module: replace a deprecated API, add proper namespaces, keep behavior. The same shape of task I would give to Rector. The difference is that the agent also handles the irregular cases Rector cannot express, the places where people wrote creative code in 2015.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dynamic properties are leaving</title>
      <link>https://useinov.com/posts/2022/dynamic-properties-deprecated/</link>
      <pubDate>Sat, 03 Sep 2022 20:30:00 +0300</pubDate>
      <guid>https://useinov.com/posts/2022/dynamic-properties-deprecated/</guid>
      <description>&lt;p&gt;&lt;code&gt;$invoice-&amp;gt;totall = 250;&lt;/code&gt; One extra letter. No error, no warning. A second property appears, the real &lt;code&gt;total&lt;/code&gt; stays null, and the bug surfaces three screens later as &amp;ldquo;total is empty sometimes&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;I have hunted this exact bug. Twice. Both times it took hours, because the write looks correct and the read looks correct. They just disagree on one letter.&lt;/p&gt;
&lt;p&gt;PHP 8.2 lands in December, and the deprecation that will touch the most code is this one. Writing to an undeclared property becomes deprecated. In some future major it becomes an error. For fifteen years it was legal:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Kohana is not developed anymore. Now what</title>
      <link>https://useinov.com/posts/2014/kohana-is-over-now-what/</link>
      <pubDate>Wed, 19 Nov 2014 19:30:00 +0300</pubDate>
      <guid>https://useinov.com/posts/2014/kohana-is-over-now-what/</guid>
      <description>&lt;p&gt;The commit log of kohana/kohana on GitHub. I opened it in the summer and counted: a few merges a month, then fewer, then nothing. This year the official development basically stopped. Our projects did not stop working on that day. But the question came to my inbox three times since, so here is the answer.&lt;/p&gt;
&lt;p&gt;What to do with a working Kohana product depends on which of four situations you are in.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
