• Cornify (unregistered)

    FILE_NOT_FOUND

  • MiserableOldGit (unregistered)

    Is that really why it was done that way? Looks more like a dyslexia attack or a cut and paste that never got finished, and no-one picked up on it in the testing.

  • Erik (unregistered) in reply to MiserableOldGit

    Who said making the property read only was intentional?

  • not a robot (unregistered)

    Read only property and property which value will not change are two different things.

  • MiserableOldGit (unregistered) in reply to Erik
    He found this unusual way of making a property read only:

    Although, granted, it doesn't state it was deliberate, just seems a funny way to phrase it if it was mistaken.

  • Sole Purpose of VIsit (unregistered)

    I suppose it's worth pointing out that "ByValue" doesn't do anything at all in the call to set. Which is just as well, really, because I'd be a little shocked if setting a property caused a change in my local variable ...

    Thing is, though, this doesn't qualify as technical debt. It qualifies as abject stupidity, yes, but not as technical debt. I haven't run it through Visual Studio and looked at the ILM, but I definitely expect the compiler to elide the nop immediately.

    "Technical debt" is when some Agile loon claims "You Ain't Gonna Need It," and a few months down the road, you find that you do (in fact) need it. You always needed it. It was obvious you needed it in the first place. But it is now impossible to satisfy that need without a major, expensive, restructuring.

    Technical debt, by definition, costs money. Stupidity? In the case quoted, stupidity comes for free!

  • PN (unregistered)

    BRAIN_NOT_FOUND

  • Christian R. Conrad (unregistered)

    "In the .Net family of languages..."

    Yeah, Anders Hejlsberg re-implemented that in C# some five-six years after he had first created it in Delphi.

  • Gerry (unregistered) in reply to Christian R. Conrad

    Indeed, it is an Object Pascal construct. When I first looked at Java, I couldn't figure out why ut DIDN'T do this.

    I don't know if it came from Delphi, from Turbo Pascal 7's objects or from the "original" Apple Object Pascal (itself derived from a Lisa language)

    The Turbo Pascal legacy object support in Delphi supports it, so I assume it is at least that old.

  • TheCPUWizard (unregistered) in reply to Sole Purpose of VIsit

    1. Do not conflate people screwing up an approach with a defect in the approach itself.

    2. YAGNI is quite real, and quite expensive. Unfortunately people screw up and presume they are not going to need something important

    3. Technical Debt has many sources, it is the result of any work effort that incurs later costs as the result of mistakes. At the same time, Debt does not really matter, it is the Interest on the debt that can kill you.

  • Free Bird (unregistered) in reply to Sole Purpose of VIsit

    That's not technical debt. Get your terminology straight.

  • Sole Purpose of VIsit (unregistered) in reply to TheCPUWizard

    1. I'm not. My observations is not meant to be global. The problem with a discussion over the Internet is that every statement you make is interpreted as being global. So -- consider my statement qualified by answers to 2 & 3. (And further qualified by a potential onwards discussion that, let's be honest, none of us have an inclination for.)

    2. True on both counts. But I think we've both seen cases where "YAGNI" is used as a sort of "appeal to authority," replacing an actual argument for why you ain't gonna need it. "Let's not build this application with a proper threaded architecture" springs immediately to mind. I claim that this happens more often than the cases where YAGNI is actually appropriate -- for failures of the latter type, consider any number of frameworks. Or, more simply, just about any implementation of the Visitor Pattern* you have ever seen.

    3. Also correct. I should have made it plain that I consider YAGNI to be a leading cause, but by no means the only cause. I like your analogy of interest on the tech debt -- this is very true.

    What it all boils down to is, make sure somebody "as competent as possible" (for some definition of competent; not my definition) is checking things out. If that person is wasting time on trivia like the OP -- gently take them to one side and explain your preferred definition of technical debt.

    And if your preferred definition of technical debt is what Free Bird apparently thinks it is -- have a nice day in the sand-pit, kiddies!

  • Sole Purpose of VIsit (unregistered)
    • The Visitor Pattern is absolutely fine if you need double dispatch in a language (presumably procedural) that doesn't supply the relevant syntactic sugar. It's also apparently very useful in the scenario described by the GoF, although I have to say I've never seen that scenario from 1995 until now. But it's astonishing how many people dive straight in and obfuscate a simple task by using it.

    YAGNI is a great rallying cry. But it doesn't actually mean much if people abide by the letter but ignore the intent.

  • TheCPUWizard (unregistered) in reply to Sole Purpose of VIsit

    1,2,3 - with the additional information I think we are largely in agreement.

    btw: I only saw "That's not technical debt. Get your terminology straight." from FreeBird, so I have no clue what that person thinks technical debt is...

  • niwax (unregistered) in reply to Christian R. Conrad

    Sort of. It had to be included in .net since it was part of VB for some time. But there also was significant overlap between VB and Delphi

Leave a comment on “Protect Your Property”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article