Leaderboard

Hello again, everyone! Who of us doesn't love getting some face time with other LAVA members? Last year we had an informal get together on Sunday night before the CLA Summit, and I am excited that we get to do it again. This year I posted first on the CLA Community page HERE, you can find details there. It is the same place this year. Again, very informal, dress comfortably. But decently, because Balla could show up and video the revelry for the poor folks back home. Jeremy Marquis CLA,CPI www.gsystems.com Just in case you cant access the CLA Community post, here it is in its entirety: ========================================================== Are you planning on attending the CLA Summit this year in Austin? Are you arriving Sunday? Would you like to meet and mingle with other LabVIEW architects? Then I have your evening plans ready! Sunday, March 4th, 6:30-10pm (or later if you want to stay, closing is 2am) G Systems will provide the food, drinks are on your own. This is an informal event which was great fun last year. Location will be The Hideout Pub They have a big patio for the nice weather, dress comfortably. They are located very close to NI, on the Southbound Mopac Frontage Road between Parmer Ln. and Duval Rd. at the intersection of Waters Park Rd./Park Bend Dr., across Mopac from St. David's North Austin Medical Center. Can't wait to see you guys again! Jeremy Marquis CLA, CPI www.gsystems.com

There are two different types of reuse, and two different "ease of use" requirements, and they oppose each other. So the answer is that you put as many restrictions on the class as makes sense for the intended usage. If I am creating a class that fulfills a niche in a product that others are going to plug into, that parent class is going to be shaped very closely to match that niche, and is going to have as many rules in place as I can have to make sure that any child classes also fit within that niche... in that case, I am *not* designing for this parent class to be pulled out of its context and so I am *not* making it easy for the person who has a use case I've never heard of. Instead, I'm trying to make it easy for the person who *wants* to fit within that niche because they're trying to implement some alternative within an existing system. If I am developing more of a "top-level library class" meant to be used in have wide utility, then I will create more "cut points" within the class, i.e., dynamic dispatch VIs where people can replace the parent class' functionality with their own. But suppose I'm looking at a class that is a top-level library class, and that class has a method A that implements the general algorithm, and A calls B that implements a detail of the algorithm, I might make both of these methods dynamic dispatch, so that new users can override either the general algorithm or can continue to reuse that general algorithm and only override B to replace a specific detail. But that has a curious effect -- anyone who overrides A never even calls B [in most cases] because B is specific to the one implementation of A and the override of A does something entirely different. That's a clue that perhaps you really want more like *two* separate classes with a strategy pattern between them. There are lots of variations. The point is that the parent has to decide which use case it is going to serve, and if it is serving the "I'm helping children to fit this niche" then it benefits from more ability to specify exactly the dimensions of that niche and throwing every restriction in the book on its API. And the whole continuum of use cases exists, such that the language itself benefits from a class *being able* to specify these restrictions, whether or not every class actually uses them. And, yes, sometimes you have a parent class that you wish you could reuse except for some small restriction... I ran into that recently with the Actor Framework... I actually have a use case for an actor that does *not* call the parent implementation of Actor Core.vi. But removing the Must Call Parent restriction from Actor Core.vi does a disservice to the 90% use case of people trying to correctly implement actors. And, indeed, my use case *is not really an actor*. So that was a big clue to me that the inheritance might not be the best way to handle this, and I looked for other solutions.