Jump to content

crelf

Members
  • Posts

    5,759
  • Joined

  • Last visited

  • Days Won

    55

Posts posted by crelf

  1. I can understand how the tangent of terminology arose from the way I worded this question, but I was referrering to the use of a Class Control and Class Indicator (with whatever name label) wired into the top I/O ConPane terminals, and a straight wire shorting the input to the output on the class (a straight wire connecting the two, because without any private data elements, you couldn't do anything else!). The purpose of this practice would allow the dynamic dispatch ability, but this contradicts with my other constraint of no inheritance.

    If we bring inheritance and function overrides back in play, a DD input is required, whether it's misleading or not (there is argument whether the output should exist since the method is not able to modify an object that contains no elements). Asking #3 remains asinine, because the object input terminal is a requirement, not a matter of elegance or coherence.

    I read the question as, "If I leave it as a class but don't need state data or inheritance, is it inelegant or misleading to have class terminals on the methods?"

    I think it's misleading - you've essentially got inputs and outputs that aren't used for anything (no state data, no inheritance), so why have them there? It would lead me to think that there's either state data (more probable) or you're forcing inheritance (less probable). Why have any inputs/outputs that aren't doing anything? Doing so suggests to others that they have a purpose. Unless, of course, you're reserving them for future fucntionality, and then you should label them so and make them "Optional" connections.

  2. Please check out my new blog, the Gun Book Review, when you have a few minutes to waste. It's a tongue-in-cheek parody of serious review-type blogs where I'll discuss one of the things I do for pleasure (when I'm not programming in LabVIEW).

    More importantly, you ride a Honda Shadow Aero? I ride a Shadow ACE.

  3. I'm saying "If you do use Object, it better be because you're applying to a generic hierarchy."

    No, you said:

    I would consider it a style fail to name a terminal "Object" unless the terminal was some type of class (LV class, .NET class, VI Server class, etc).

    Which I took to mean I couldn't use the word "object" unless it refered to a software engineering object. The generic hierachy could be anything, not necessarily a software engineering class.

  4. There have been a couple of interesting threads where interesting thoughts were exchanged right up till the inverse of "Kring's Law" was invoked and the thread shut down and deleted...
    I'm not sure if you talking about LAVA and/or other fourm(s), but rest assured that we try really hard to leave threads alone, especially those in the LAVA Lounge, where just about anything goes. There have been occasional moderator interventions, but they usually only come when a member contacts us and asks us to do so - and even then we make a judgement call on whether to step in or not. Even then we usually ask everyone on the thread to cool down for a while. It's very rare for us to lock a thread, and almost unheard of for us to delete a thread (unless it's spam, for example). If you think a post or thread of yours has been unfaily handled, please let us know - anything we delete remains in the moderator trash can for a period of time, and we'll review it for un-deletion. We're a group of people, so we might make a call that's wrong, and we're always open to taking a second look.
    I sincerley hope I have not offened anyone and welcome any and all that would like to share their insight.

    That's the spirit!

    "the truth does not have an agenda."

    Right - except that it's difficult to articulate a truth with with our inefficient communcation abilities, and even more difficult to perceive one communicated to us. In short, we spin, based on our own experiences, environment, and perceptions of those we're conveying to/from.

    • Like 1
  5. I don't think it matters much if Wikileaks broke the law. The ones that clearly broke the law are the ones that provided classified information to them. There's not much question on this point. If one agrees to protect the information as a condition of having access, I don't think that an individual can then just decide not to abide by the law/his contract/etc. If there's a real specific instance of wrongdoing, the I might see releasing that information to an attorney in confidence who could then build a case. Just anonymously dumping massive amounts of classified and sensitive data to Wikileaks is the action of a disgruntled coward.

    Disgruntled? Perhaps. Coward? Not sure how you can make that leap.

    I can honestly say I'm on both sides of the fence on this issue. What Wilileaks has been doing, to their credit, is doing the job the media is supposed to be doing but refuses to do.... On the other hand, I can see where the individual who discloses classified information is a disgruntled coward. But I don't see where this is the fault of Wikileaks.

    Well put Paul! Kudos +1.

    Sorry about the thread derail...:oops:

    Moved to it's own thread :)

  6. Libraries allow for private methods, so the encapsulation of methods would not be a reason to keep these collections as classes.

    No, he's not. That's the whole "stateless" part of his original post. With no data in the cluster, and no inheritance to add any (either real data or the meta data of runtime type), there's no object instantiation at all.

    I agree.

    I would consider it a style fail to name a terminal "Object" unless the terminal was some type of class (LV class, .NET class, VI Server class, etc).

    I disagree. I think of the thing on the FP and connector pane as the thing - not the type of thing. If you can use a more specific name then go for it, but if it really is an "object" in whatever field it's being applied to then I say use that name - don't avoid it just because there's a LabVIEW datatype with the same name.

  7. Consider a LVClass that has been reduced to the point where it has no Class Private Data - its objects are stateless. Also, consider this class is not part of a class hierarchy, so inheritance does not come into play. Should I "demote" this class to a "mere" Library?

    I'd say yes. OO's big three are encapsulation, instantiation, and inheritance. Since you don't have any privates (*giggle*) you don't need encapsulation (unless you want private *methods* - that's an important distinction), instantiation isn't limited to LVOOP since everything's by-val anyway) and you don't need ingeritance. That said, there's no harm in leaving it as a class - as jgcode said, namespacing could be an issue, and if you're okay with the class as it is, then I don't think you need to demote it.

    Is it inelegant or misleading to leave the class as a class?

    Hmmmm - that's a good question. I don't think it's an issue. I see a lvlib as a collection of related VIs, whereas a class is a collection of related VIs that act on an object - I'm assuming that you're still going to have an object, right? Like a cluster of something that passes between the VIs? If so, I'd stay with a class - it's easier to manage (the prototype of the object is in the class, not as a separate ctl file).

    If it is to remain a class, is it inelegant or misleading to have Object In and Object Out terminals on the methods?

    Using the work "Object" doesn't mean that it must be of type class. If it can be considered an object (eg" a file, something in the real world, a DAQ card, etc) then that's fine. That said, I usually don't use the word "object" in the names of my objects - because that's the type of the input/output. It'be like calling your numeric inputs and outputs "Numeric In" and "Numeric Out" - call them what they actually represent (eg: "Configuration File" or "DAQ Card", etc).

  8. I'm curious though, are any business decisions made on the basis of the quality metric, or is it just something for managers to fuss over?

    Yes, and yes. The quality metric can be useful in tracking when a software product has acheived a steady state. It's common to think of a project as finished when two things occur: when all the requirements are met, and when the quality it acceptable. I'll leave it to another time to discuss "acceptable" :) So, in tracking the requirements coverage (NIRG is seriously excellent for that - it's seriously one of NI's least appreciated offerings - see an example of one of our project templates below) and quality, you don't have to rely on "I'm-almost-done" statements from engineers (hey, we all know how flaky they can be).

    post-181-0-12942200-1294842244_thumb.jpg

  9. 1. Maximizing screens

    ...

    1. This is going to be difficult for me to change. I wish I could spend some time watching some experts develop, because I find myself spending too much time putting the mouse to the scroll bars to go where I want in the VI when not maximizing. The best developers seem to all use non-maximized screens, so I'm thinking there must be something that I'm missing. I develop slower when I'm using non-maximized screens. But I see the rather huge incremental benefit for not maximizing, I'm just not doing something correctly. I'm currently not maximizing in any case where it isn't clearly warranted, but it continues to be painful, and I don't see a light at the end of the tunnel.

    Unless I'm misunderstanding what you mean, I don't see this as a bad habit at all. I often start with a large (not always maxmized, but usually lfar larger than I think I'll need) BD, write my code, then I arrange things to a more pleasing layout, then I resize the window to suit. That one resize at the end is much better than several resizes in the middle to make the BD larger - that would really get in the way of my (data)flow.

    The best developers seem to all use non-maximized screens...

    Reference please - I've never heard that.

    Remove distractions.

    Damn right! Although we have the white noise thing going on here (and it makes a big difference), we have a "quiet room" set up with two mega-workstations with docks, comfy chairs (including a couple for reading) where anyone can go to get away from it all. The rules are simple:

    • no cell phones
    • no talking
    • if the door is closed, don't bother anyone in there unless it's an emergency (eg: the "building is on fire!", not "Can I eat your pizza rolls in the freezer?")

    I once avoided my boss for days in that room...

    • Like 1
  10. IN this day of no body trust nobody, wikileaks seems to be a single source of info that few question.

    I'm still not quite sure what wikileaks has done wrong. There seems to be a lot of angst, but not much info on what laws they've broken.

    • Like 1
×
×
  • Create New...

Important Information

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