Jump to content

Val Brown

  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Val Brown

  1. I posted a reply to MJE, but one section of my post there is relevant here:


    > When I add a flexibility point, I prefer to do it in response to some user need, not just on the off chance that

    > someone might need it because every one of those points of flexibility for an end user becomes a point of

    > inflexibility for the API developer, and, ultimately, that limits the ability of the API to flex to meet use cases.


    That pretty much sums up what I've learned over my years of programming for component development.


    I had actually been putting together notes -- based on this conversation -- for a concept I was calling "a class' optional straightjacket". Where it falls short -- at the moment -- is module interoperability. Suppose we say that "all actors will stop instantly all activity upon receiving an Emergency Stop message". And we made that an optional straightjacket for actor classes. An actor that chose not to live by the straightjacket isn't just a loose actor, it is actually not an actor... it's ability to be reused in other systems is actually decreased. It is, in a sense, unreliable.


    That lead me to consider "a class that chooses not to wear the straightjacket *is not a value of the parent class*". Bear with me here, because these notes are a work in progress, but you brought it up. If a parent class has a straightjacket to let it be used in an application, and the child class chooses not to wear the straightjacket, then it can still inherit all the parent class functionality, but it cannot be used in a framework that expects classes that use the straightjacket. This makes it very different from an Interface or a Trait because the parent class *does* wear the straightjacket, but inherited children do not necessarily do so.




    FWIW, I agree with all of what you're saying here.  The idea of allowing for "advanced users to be flexible" is fine, but then, those same advanced users can be as flexible as they like -- with code THEY develop.

  2. No, nothing REQUIRES byref implementations, however, for various reasons (including what appears most "natural and simple" to an individual) the DVR implementations may be preferred. You might want to look at for one of the threads discussing this issue.

    It depends, in the end, on what you mean but I've always been struck by how much the legacy of a primacy effect impacts these kinds of discussions. For instance, if you learned C++ first, you most likely learned of "singleton" in terms of byref implementations. If, however, you learned C first (esp if you were involved in the earliest standardization efforts of C), you probably didn't learn of it in that way as "classes" per se didn't yet exist. Instead all of the various semaphore "tricks" or, if you prefer "workarounds", became familiar to you and you might even continue to PREFER to have the increased flexibility of NOT being restricted by the now-classic implementation of "singleton" in C++. As you can guess, my history extends beyond the early days of C (in fact all the way to PL/1, FORTRAN, etc) and so I prefer the more purely "dataflow" implementations using SEQ+FGV instead of DVRs. But unless you demand the strictest definition of "singleton" (a la the C++ construct), it is clear that nothing does require byref.

  3. I disagree. Most of the patterns used in OOP design are build around the very principle of references. References to objects. How do you make a singleton without using some kind of reference? You can do it with LV2 style globals, sort of. But when using a DVR, the whole process becomes much more natural and stright forward, and you stick to the principles of dataflow. You could say that when using dataflow you can do well without a singleton, but then you also end up way outside true and trusted OOP design patterns that have proven their usefullness over and over. Sometimes the data is the reference, sometimes it is the value, it's still dataflow IMO.

    You're basically remaking my point. "Most of the patterns..." are programmed in C++ by those who use and "grew up" using/learning programming constructs via C++ and/or UML oriented to byref constructs. And what is "more natural and straight forward" depends on the eyes of the beholder. Having used LV as long as I have, FGV seem VERY natural and straight forward to me.

  4. Absolutely nothing about OOP requires a by reference design.

    Even if 99.99% of OOP Implementations DO use references, it does not change the matter that the very nature of OOP does not demand either by value or by reference idioms.


    This is exactly correct. Nothing absolutely requires references it's just that some come from the perspective of C++ as THE gold standard for how OOP is to be implemented and, since C++ is generally taught musing byref constructs, it's implicit that such an implementation is "better" or "fundamentally different" in some preferable manner -- generally in terms of "ease", "readability" or some similar criteria in the mind of the person making that judgement.

    Like almost all language related discussions, it reflects much more the biases and history of those involved in the discussion rather than any structural realities OF the language. Parisians cringe at Quebecois and vice versa and both wag their heads at Cajun Creole.

    Of course you could say that I have a bias. After all, all of my programming is byval..... :yes:

  5. I'd like to ask a related question but, if it seems like that is hijacking this thread, I'll move it somewhere else. I'm looking into including mpc-hc.exe as part of a distribution. It would be the version already "out there" under LGPL (as I understand it) and I would not be using ANY of the source code to it (let alone modifying it) but would instead simply call npc-hc.exe and dispatch text commands to it to implement a few key functions that MS, in it's infinite wisdom, have closed off in WMP in Windows 8.

    What is the understanding that others have about what notices are required to do this and does doing this open me up to the possibility of having to post my source code (which I will never do).

  6. Coding Without Comments


    "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

    Brian Kernighan, "The Elements of Programming Style", 2nd edition, chapter 2

    I remember

    Ritchie, Thompson, Plougher and Kernighan all talking about the merits of obscurity when trying to protect IP. It's an important lesson to bear in mind when considering how "easy" you want to your code for those who might follow...

    Of course, we all DID know that Ritchie and Thompson left open some back doors, even though they denied it for many, many years.
  7. I've used the KeySpan 19HS but don't have a URL ready to hand about it. And I agree with Neville D that the TFDI chipset adapters seem to have been the most reliable, if memory serves.

    I seem to remember that there was a large in how VISA errors were handled in shifting from 6 to 7, and then again in the shift to 8.x.. Somewhere along the way the "Legacy I/O" VIs went bye bye, but they still did function through, I believe the last version before the release of 2009.

    I thought I'd given up serial communications back in the early 80s after implementing a Unix look a like for 4 work stations networked to an old 8086. Oh well.....

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.