Basilevs

Thank you for clarification.

Anyway, my wording turned out to be excessively dramatic, causing misunderstandings. We have enough mutual understanding that it is not really important.

Or scope of a task in general.

I do not argue about presence of a commit, I argue about unit of work.

The hole might be a part of the process, but my point is that it is not an important enough part to be considered separately.

@GregBurghardt I see what you mean. But the process as a whole is not a refactoring here. It is just "getting things done". Then post is installed, cement holds the post. Job is done. There is no refactoring, just normal implementation.

@GregBurghardt Have been with you until "cannot define" if there is no place for the small change in the large picture, why do said small change?

I don't see how losing a related change in the next release is "done by itself". Such refactoring is still a part of a plan. It is not by itself. The specific timings of plan items are irrelevant.

@GregBurghardt A refactoring that lost its "client" to the next release is not a big deal. Just the one, where there is no "client" in sight is.

@GregBurghardt Well, we are not talking about commits here, so this should be fine, right?

Yep, I've reread Steve's answer. He keeps trying to rationalize an unnecessary refactoring referring to intuition. This is a poor argument, but otherwise our answers have no direct contradictions.

@GregBurghardt I assumed refactoring is a code change without a change in behavior, but potential changes in structure. It is hard to misinterpret. It would be nice if someone pointed out my misunderstanding in more detail. I guess I'll reread Steve's answer, but so far nothing there contradicts mine (except invalid rationales).

@GregBurghardt "refactoring means changing the code without changing it's behavior" - if behavior is unchanged, the code change is unnecessary. And any change is dangerous (may lead to regressions). Therefore, all code changes have to lead to behavior changes. Hence the catchword.

@Ewan what are comments for your refactoring commits? Do they mention features? Explain why the refactoring was done? What is the percentage of refactoring commits without any relationship to a feature? I beleive if you really look carefully, those commits would be a part of feature/bug implementation. This is what I mean by "refactoring does not exist".

@Ewan, refactoring is done in the first commit. Prototype is thrown out. I'll add clarification.

Prototype may include any changes including those that help with understanding, do whatever is necessary, but no more.

@RohitGupta why are you looking at it? Stop if it does not help to implement a feature.

@Craig yes, but "using" has nothing to do with "include" in C++. I think this contradicts your original statement.

@candied_orange My corrections were only applied after weeks of moderation. So that could be a hint of liability.

@candied_orange Oh, that reminds me. I've moved countries and lost the ability to post corrections to Google Maps. They have different approaches depending on the area!

But malicious business can still direct people to the government territory, so the original question is unanswered.

True, Google maps have all these functions. But we are designing a new map application here (for the question to be on-topic). I guess the solution is to only allow businesses to modify routes where the destination is a specific business.

See my second comment - the business may indicate the ADDRESS is in the restricted area and manipulate navigation hints to have unfair advantage.

Existing APIs (can) use street address as a destination. If a business is allowed to restrict an access to the address, they could direct the traffic to themselves instead of a competitor on the same address.

Option 2 seems to bee invalid, as one business (even non-existent one) could obstruct unrelated businesses in a malpractice.

@IncnisMrsi nothing is bad with it. It is an example of complexity, that overshadows your block translation worries.

@IncnisMrsi 🫤 it has directories, tables and fragmentation.

@IncnisMrsi Not a problem, as any software including UEFI, has plenty of layers. Some of those can couple/transform one format to another. I do not know how it is done exactly, sure, but as a reminder, UEFI can read FAT32, which is complex enough.

@IncnisMrsi Sorry, I do not like the "piece of hardware" part here. This may as well be done by software. It does not really matter. I also don't see how anything is simpler than byte-stream.

@IncnisMrsi an abstraction over hardware specifics. Abstractions may be OS independent.

@IncnisMrsi For some reason, I was under impression, that LBA size is not important for GPT - it may be used to communicate to the disk by driver, but GPT works on higher level splitting octets anew. I don't want to look it up now, so I'm going to watch answers for your question :)

@IncnisMrsi Yes, I've meant software in general. The interface is important, but it is hidden from FS layer by device driver.

@IncnisMrsi Drive can do whatever it wants, the OS is free to ignore that and use a different block scheme.

I'm not sure what the quote about LBA means in conext of our discussion. Is it irrelevant given, that it is only provided for compatibility with older OS?

To be fair I'm not aware of formal definition and there does not seem to be a standard. What I meant by "logical sectors" are sectors observed by tooling like in this article

@IncnisMrsi could you clarify in the question, that you are interested in logical sector size? I was confused by the middle of the question.

@IncnisMrsi but those are logical sectors, not hardware ones. So bootloading has nothing to do with hardware.

@IncnisMrsi, logical unit size is in general unrelated to physical size (ignoring performance). Does UEFI really use sector-based addressing for bootloading? It seems to use FAT32 instead

GPT does not work with hardware. It is a high-level logical structure just like filesystems it contains. Why would it mention or use sector or any other physical information? The sector information may be important on device driver level, but not on filesystem level.

@candied_orange that's my point - if no postconditions are observable, method can do whatever it wants.

@candied_orange neither null object nor log interfaces have observable post-conditions for clients, so they are fine.

@candied_orange remember LSP - similar principle applies. Any method implementation is allowed as long as it behaves to contract.

@candied_orange internally method can do whatever. But external observer should see expected result. If (observable) promise is broken, the method name is incorrect. Introduce a new method with new contract/promise and a different name.

@candied_orange your point would be even better communicated if you just post the last message from chat - "the natural language from method name does not establish postcondition contract". Because you argue that methods can be configured to do nothing, I argue, that natural language communicates that method promises something and we are at impasse.

Let us continue this discussion in chat.

@Caleth What return value do you require from updateUI() method and why? It may leave old values in place if they match new. User does not care whether the actual UI event happens.

@Caleth noop post-condition for a method without return value makes no sense.

Jump is the worst example, because in natural language it may have a noop post-condition (jump in-place by default). I request an example with "jumpDown()" or "jumpOut()"

@candied_orange I see your point now. I guess a local standard defines a degree to which names communicate contracts.

@candied_orange implementation should not be a part of contract.