Daklu

"Sonja" is much more fitting for something this sexy.

Methinks Chris knows more than he is letting on...

On reflection I think your interpretation is far better. Just because the parent object isn't instantiated doesn't mean it can't have useful code implemented in it's methods. (Though I do prefer 'abstract' over 'pure virtual.') The word "interface" is a bit tricky because it is ambiguous. Sometimes it is used to mean an Interface type, which is distinctly different from a class type; sometimes it is used to mean the public API exposed by a module, which may or may not include classes and methods. The class Budd describes has some similarities to Interfaces (namely that there is no implementation), but it still lacks the key features that make it an Interface type. Calling it an Interface implies it has certain capabilities that it, in fact, does not. It looks to me like it's a subset of abstract classes. (We could call it "fully abstracted," but I'm having a hard time convincing myself that we even need to bother with defining it.) Since Labview doesn't natively support Interfaces, I rarely use the (capitalized) term. "interfaces" (with a lower case 'i' to mean a public api) is such a general and useful term in programming that I would be very reluctant to restrict its use to specific implementations (or lack thereof.) I did the same in starting with fully abstract classes and eventually came to the same conclusion you did--there's no reason not to put common behavior in the parent class. And it's far easier to accept changing a fully abstracted class into just an abstract class than it is to change an Interface into an abstract class. I don't have my copy of Head First handy, but in UML can't the stereotype <<interface>> mean either the type or an api?

Interesting insights Felix. You've done far more research into UML and generalized OOP than I have, so I'll defer to you on those topics. I use adapters all the time for my hardware abstraction layer. It allows me to create independent (derive from LVObject) and reusable device-specific classes for our instruments without having to try and fit instruments with different capabilities into the same class hierarchy. It does require a little more application-specific code and goes against our instinct to "reuse everything," but I've found it is far more flexible, easier to maintain, and easier to extend. Do you mean when OOP programming first got started back in the 60's? I'm not sure I'm following your meaning. In the languages I'm familiar with Interfaces behave differently than classes so I guess it's not surprising UML treats them differently. An interface can be a facade (as defined by GoF,) but an Interface cannot. Facades provide a single simplified access point to a group of related classes that provide some functionality to the rest of the application. It allows the app-level code to only have to worry about the facade class instead of managing all of the classes that make up the subsystem. The Interface Framework follows the adapter pattern much more closely than the facade pattern. Be interesting to see if that's applicable to any LV concepts.

Thanks for the tip! I like it for quick one-off diagrams such as to illustrate a point on the forums. It appears to lack any sort of project that provides the conveniences of common uml objects across multiple diagrams, so it doesn't replace Enterprise Architect or Star UML for larger projects, but it does have a useful purpose.

As you've no doubt discovered, OO terminology has slightly different meanings in Labview than in other languages. To aid discussion, here's how I think about some common terms: abstract method - Text languages use the 'abstract' keyword to define methods that are defined, but not implemented. Labview doesn't have an abstract keyword, so an abstract method is simply a parent method that doesn't have any code on the block diagram. All your aAlgorithm methods are abstract. abstract class - Text languages use the 'abstract' keyword to define classes that cannot be instantiated. In Labview it is impossible to create a type that cannot be instantiated. If it exists on the block diagram or front panel it will be instantiated at runtime. I use "abstract class" in Labview to refer to a class in which all the methods are abstract, like aAlgorithm. In my mind if any methods are implemented the class is no longer abstract. In text languages you cannot instantiate an abstract class. In Labview there is no reason to use an abstract class in your code other than as a type definition. (Don't confuse that with me saying there's no reason to have an abstract class in your project.) interface - The generic term means pretty much the same thing in both Labview and text languages. Abstract methods and abstract classes are interfaces, but interfaces are not always abstract. Interface (with a capital 'I') - These exist as a specific construct in text languages and have no native correlation in Labview. I use the term to refer to classes that derive from the IUnknown class in the Interface framework. ----------------------- Your implementation seems to be quite reasonable, though strictly speaking I think it is closer to the template method pattern as defined by GoF than the strategy pattern; however, I'm not convinced these two patterns are actually different patterns and not just slight variations of the same thing. One thing to consider is whether you need aAlgorithm in your hierarchy. I've found that usually using an abstract class is simply extra code, especially in a single-module application. Providing some sort of default implementation makes more sense to me in the context of data flow and reduces complexity. It also means I don't have to raise errors in each of the abstract class' methods just in case someone accidentally writes code that calls one. In your example I would consider replacing aAlgorithm with Algorithm 1. That's not to say that I never use abstract classes. Suppose aAlgorithm defines 10 methods and each subclass implements a unique combination of 2 of them. If aAlgorithm provides a default implementation then your child classes not only have to override the abstract methods to provide an appropriate implementation but also have to override the parent's implemented methods to "blank" them. I've been down that path and thought it was more confusing. My current working rule of thumb is to use an abstract class when I expect child classes will need to blank a parent method. (I'll also use abstract classes across code module boundaries when a default implementation is meaningless, but that's a more complex use case.) I don't think using Interfaces to implement the strategy pattern is a good idea in any language. Interfaces are best used to expose common behavior across otherwise unrelated classes. For instance, I could have a Dinosaur object, a SodaCan object, and a NetworkConnection object. If I want to save them all to disk it might make sense to create an ISerializable or IPersistable Interface class to implement that functionality. Strategy algorithms are related so using Interfaces is just extra work IMO. If having all your algorithm classes derive from the same parent is a problem (perhaps your algorithms classes are already pre-defined) then using adapter classes is a better solution than Interfaces. The diagram below shows how that is implemented. Incidentally, I haven't had a chance to look over your code on the other thread but it is on my to-do list. -Dave

There are cool kids here?

I can't say I've run into this particular problem, yet I'm fairly certain I've distributed reuse code using community scoped methods. It could be that I friended specific vis rather than an entire library. That's one work around. A possible (though ugly) work around is to edit .lvlib file and change the friend path to the location where you exepct the addon to be located. [Later...] Stepping back a bit and taking a broader view I think your deployment model is flawed. You're deploying the Api module first, then developing the extended Api (xApi) module as an addon against it. Even if you could define friends by name the addon developer would have to use your predefined name for the addon to work. That's not really addon-ish behavior. If the functions in Api and xApi are closely related they should be deployed together in a single module. Use virtual folders and sub palettes to segregate the xApi functions. If they are different enough to warrant two separate deployment modules you might be able to achieve what you're after by restructuring your libraries. Create a project file that contains three libraries: Api.lvlib, xApi.lvlib, and Common.lvlib. Take all the community vis from Api and put them in Common. Make Api and xApi friends of Common. When you create builds for Api and xApi, the modules will each carry their own copy of Common, so to avoid cross linking you'll have to give the library unique names during the build. I don't understand how linking by name instead of by path makes a friend more or less able to alter data. Can you explain?

Personally I'm not interested in UML code generation. By the time your UML tool has enough information to create the code the way you want it you've essentially created a completely separate programming language. For me UML's main value is in the thought process I go through while creating the models. At the same time, it's not uncommon for me to discover an overlooked problem in my model while implementing it. I might miss that using automatic code generation. That said, I'm not a stickler for adhering to the UML standard as long as I can accurately convey my design intent. Supporting the diagrams I use and a good UI are more important to me that strict standard compliance. I use Enterprise Architect for my modelling and I have a hard time figuring out how to model certain things. Maybe it's because I'm still learning how to model correctly; maybe it's because UML doesn't support Labview ideas very well. I can't say for certain either way. (It's probably a combination of both.) As for StarUML, I like it lightness (and cheapness) for hobby or open source projects, but I certainly wouldn't base business critical processes on it. (As a matter of fact I'll probably use it for LapDog unless there is a compelling free alternative.)

Could be, but forking and spooning are often closely related, so I didn't make the distinction.

Redownloaded and got the same error. Copied the file over to my flash drive and it works. Weird. "The new features for LabVIEW 2011 will be a handful of very cool features (including a few from the LabVIEW Idea Exchange) and a huge number of bug fixes, editor performance upgrades and compiler optimizations. This decision comes in response to your user feedback." Kudos to NI for making this call.

The attached ppt was corrupted in my download. Anyone else have this problem?

Erm... "Regardless I'd like to move all discussions over to the community site so we have a single point for information." There is a spoon, we're just hiding it while we figure out what the spoon will look like.

Sparc is right. You can see the offset if you zoom in on your acceleration data.

And the Sheila to your right followed your lead. That's gotta be worth something. Depends on your point of view. Seems to me he was paying attention to the wrong thing...

So hopefully everyone has sobered up from NI Week. In planning for 2011 I'd like to know what people's experience with the local hotels was like and how much I should expect to pay. I checked a couple online and got prices from $140/night to $350/night.

Sorry Jeff, it looks like you were accidentally left off the group pm. We have a private community set up on NI's website. Send me a pm with your NI logon name and I'll send you an invitation to join the group.

Dan, I have absolutely no experience with ORM and the last time I did anything substantial with databases was in the late '90's using VB6. So while I personally wouldn't be much help to you, it looks like there are other developers who would. LapDog has a private community on NI's website. (We'll open it up eventually but since we're just starting out I'd like to keep it small.) If you'd like to see what we're about post your NI logon name and someone will send you an invite. There's not a lot of activity just yet, but I've posted some documents outlining my vision and those should give you a sense of our direction. -Dave "I asked Daklu to add you to the discussion there." Jon started that private discussion thread--I can't add members. Regardless I'd like to move all discussions over to the community site so we have a single point for information.

What was the challenge?

Damn the finances! I feel so bad missing out on all the fun I decided to sell my children into slavery to pay for next year. (According to them that would be a step up in social status...) How far in advance does NI schedule NI Week? I figure if I book my reservations now there's less chance of me backing out.

Or you could tweak it a bit and make it compatible with by-value classes. I solved that problem by "casting" the object to an interface and then "casting" it back into the original object. You can certainly do that--your implementation would still be different enough from mine that it would benefit the community to have both and see which one is more useful. If you come up with an alternative solution I'd be really interested in seeing it.

Don't they already exist? Every once in while somebody pops on the board with a question about how to update a LV version 3 vi to the current version. If that's not paleolabviewology then I don't know what is.

Thanks Darren and Crossrulz for clearing that up.

So each question has three rating categories. "Frequency" and "Today's Performance" are self-explanatory, but I have not idea what "Expected Work" is supposed to mean. Is that how much work we expect NI to put into that feature?