Hacker News Reader

Comment by k__ | Hacker News Reader

Philosophically speaking, is it really hidden control flow if a function call just happens to look like a attribute access?

View on HN

When reading code in a low level setting you may want to know whether one line calls a function or simply reads a field from memory. Not that it would matter that much, but it's a valid point for some. Reading a field is usually expected to not induce any control flow

> When reading code in a low level setting you may want to know whether one line calls a function or simply reads a field from memory.

Unless you ditch optimizations completely, it is hard to know without looking at the generated asm. Of course you can make educated guesses.

The idea in D is to make the following unnecessary:

    struct S {
        int m_field;
        int field() { return m_field; }
        void field(int c) { m_field = x; }
    }

just to future proof the field access. Don't bother with the access functions until they are actually needed.

The actual feature that languages should implement is lenses, prisms and optics which are like properties except made properly composable and enabling high-level optimizations, for a similar efficiency to "bare" field access.

I’ve never heard of those. Do you have a link explaining them?

I've only seen flow control used in the context of conditional branching, so if the function contains no branches, I don't see why it would. Hidden overhead or indirection, sure, but not necessarily flow control, for the same reason e.g. indirect pointer access isn't.

function calls are, themselves, branches.

underneath there is literally assembly to take current state, push it to the stack, then jump into another location in memory and start executing.

And then when done, do the reverse. jump back to another memory location and pop everything back off the aforementioned stack and into registers.

Yes, but that's not a conditional branch, and that's the distinction I've always seen made for flow control versus indirection

try/catch/finally is also considered control flow and it's not conditional, although, unfortunately I've seen people use it as a control flow mechanism.

interrupts are also control flow but, again, there are no conditionals there.

control flow is about the order of execution, one common way to get there is using conditionals, but it's not the only way.

Having said that, even if you disagree with Andrew's wording, the overarching idea remains. You always know explicitly if the flow changes.

try/catch seems very conditional to me. If there is an error condition, jump to the error handling code. Or am I missing something?

I could also describe a JMP instruction as "if you got here, jump to there", but just because I can doesn't necessarily mean I should.

But Try, catch and throw are in themselves not conditional, they are fancy gotos with bookkeeping. Those constructs don’t typically deal with conditions.

However I think the notion that “flow control” has to do only with conditionals is not a common one. FWIW the definition on Wikipedia, which aligns with my experience is not this restrictive… the lowly goto is flow control. Basically anything that controls the program location is flow control.

Yeah, but raising the error is the conditional in there. Which, to me, makes the try catch conditional as well, but that may be a case of differing semantics.

Yeah, flow control isn't just conditional jumps. You can kinda treat branchless code as a form of flow control as well.

> You can kinda treat branchless code as a form of flow control as well.

That's the common understanding of flow control, the other poster is right in that it's not typically just conditionals. There are a few posters who were under that misapprehension, but that's never been the common understanding of it, it's just that conditionals are typically where people worry over flow control because otherwise it's linear.

I haven’t usually used such a restrictive definition, flow control is any mechanism that directs program location. https://en.wikipedia.org/wiki/Control_flow

And flow control and indirection are not two concepts I’ve ever grouped together as complementary either. A function call is not something I’ve ever heard as “indirection”.

Yes. That can affect performance and also cause spooky action at a distance. Suppose someone less careful put some code in the accessor function mutates global state. Do you want to be checking all of your objects all the time to see if they are doing something counterintuitive?

Interesting that this is seen as a negative, C# has getters/setters that look like property access, but I don’t think I ever heard anyone complain about this.

zig and c# each scratch a different itch.

Yeah, of course. But the issue would still be the same in this case.

While the issue is the same, context can make things different. In Ruby, I love proxy objects returned from accessors. In Rust, I wouldn't even support adding accessors to the language. Different goals and objectives.

C# inherited it from Delphi, so there's plenty of experience showing that this is not an issue in practice. Thing is, if you don't have accessor methods (or some equivalent syntactic sugar as in D) in a OO language, you end up with them anyway, just ad hoc like Java's get/set methods. And then you still have to think about which methods that look like they're pure queries might actually mutate shared state.

If anything, I would argue that explicit accessors make it clearer because in e.g. C# you can't write a method that looks like a getter (but mutates state) by accidentally naming it as such. If someone made something a property, that's because they thought its semantics are property-like, which includes not mutating global state. Sure, people will still get that wrong occasionally, just as they run mutating "get" methods, but it is surprisingly rare.

> because they thought its semantics are property-like,

Suppose you include a logging statement in your accessor, which hides a race condition. You're gonna tear your hair out.

Suppose you do the same in your getWhatever() method instead; what's the difference? If every property access is an explicit method call, the mental overhead on the API client is the same in practice, since most of those method calls are still semantically property-like and are treated as such.

C++ Builder also has them in their extensions to C++. My guess is that it looks convenient for languages that have a de facto GUI framework/library. In Delphi/Object Pascal, C#, C++ Builder, it becomes convenient to, for example, change a button's text as if assigning to its text value. And it is often taken for granted how the form's UI just "magically" updates. I'm pretty sure classic VB's control "properties" work that way as well.

When I was new to their corresponding GUI frameworks, the dot + property notation was appealing because it looked clean. However, as I got more experienced I'm no longer seeing the advantage of saving two parentheses characters at the expense of potentially hiding function calls where anything can happen.

I'm not sure why D joined the club given it doesn't have a corresponding de facto GUI framework, and its users even discourage it.

I found a use for the overriding field access once, when there was a large data structure bit-packed into a byte array. I didn't really need to convert it to a different data structure, but to just extract some values, and pack it back to the byte array.

So I overrode the field access that operated directly on the byte array.

PS: It was in Kotlin, using @get/@set, but it doesn't matter for the philosophy.

"If a tree falls in the woods and no one is around to hear it, does it still make a sound?"

Attribute access is reading a value, invoking a function is different (as mentioned, using a stack, etc.), although it is certainly possible a function only reads and returns a value.

All that to say my answer is yes, providing flow control mechanisms makes it flow control... and falling trees make a sound!

Reply on news.ycombinator.com