Val Brown

Right, so now we have to mindful of how we code the UI and cap the UWI.....

Way to go Fab....

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.

 

Thoughts?

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.

Val,

 

One of the advantages of being my own boss is that I already convinced her to let me go not only to one, but both!

 

Fab

Vea lo fácil que era!

I thought we could start listing some of the things others have used successfully to convince their bosses to send them to the CLA Summit.

Fab,

You could just bribe yours with a Jalapena Margarita at zTajas....

Saved for 2011:

Drag to Snap off Window 2011.zip

I'd like to be able to handle the by value data model and the by reference process model in a single unified code base so that there aren't two different programming styles depending upon which system you need/like more.

I'd like to hear more about that, if not here, then in another thread.

Can you save this for 2011?

OK, thanks.  I'll give that a try.

I'm not able to capture this as Double Click. Instead I register a single Left Click, no matter how quickly the double click is done.  Does anyone have a working example of this actually working?

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.

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.

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.

Shane.

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.....

Don't forget though that the actual complete OSDetailedName is likely to be the far longer than just "Windows 7".....

Rolf,

Thanks so much for your comments here. You're reflecting what my sense is of the situation. Anyone have a different perspective?

val

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).

Perfect. Thanks.

Anyone know the string returned to OSName when the OS is Windows 8? I don't have a test system with W8 on it so can't verify it myself yet.

Coding Without Comments

http://www.codinghor...t-comments.html

Alternately

"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'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.....

Well I'm VERY sad to say that things have changed and I will NOT at the BBQ because I will not be at NI-Week.

SO everybody have a great time....drink lots of :beer_mug: :beer_mug:

Wow, really nice web and iPhone apps. Scheduling Sessions was actually fun and easy and that's a first!

I did open a case with NI about this new feature. They were able to replicate it easy enough but I am sorry to say they will not fix it. They did offer other work arounds.

What were the other work arounds?

Actually, the working link should be:

http://secure.niweek...uler/public.jsp

Yes that's the link to the calendar itself but there is not yet a posted access to setting up your own schedule.

I just spoke to NI yesterday about this and it's not up yet.

So how many CLAs and such do we have working on this?????