Jump to content

Should parents inheret children's attributes?


Recommended Posts

Now that I've got your attention: no, this isn't an OO question. Consider a VI that has a required input. If I then drop that VI (child) into another VI (parent), create a control that wires into the required input of the subVI and then put that control on the parent's connector pane, should the parent's connector pane node become required?

A is required, should B be automatically required too?

post-181-1194462684.gif?width=400

Link to comment

QUOTE(crelf @ Nov 7 2007, 11:11 AM)

Now that I've got your attention: no, this isn't an OO question. Consider a VI that has a required input. If I then drop that VI (child) into another VI (parent), create a control that wires into the required input of the subVI and then put that control on the parent's connector pane, should the parent's connector pane node become required?

A is required, should B be automatically required too?

My first thought is that this sounds like a good candidate for a VI Analyzer test, not automatic behavior within the IDE.

Link to comment

I'm really of two minds about this. The core of your question, I think, comes from the experience we've all had of creating a control on subVI A that we're just going to wire to a terminal on the parent VI B. If A is required, and you want B to be required, it takes what, like like four extra operations to set that behavior??? That's pretty poor usability for an operation some of us have probably done hundreds of thousands of times.

But making required inputs on a subVI automatically drop as required inputs on a parent VI really just trades one side of the problem for the other side. I can't say for sure how often I want those parent inputs to be Required. I'd guess it's more than 50% of the time, but I dunno if it's as high as 75%. The other 25-50% of the time, I probably want them not to be Required. :)

So I would probably lean toward saying in your scenario they should be "Required," but I certainly can see other people coming down on the other side of the fence.

Wouldn't it be nice is the whole "connecting terminals to the connector pane and setting their attributes" process was easier in the first place, given that it's kind of a core concept of the language? :P

Link to comment

QUOTE(crelf @ Nov 7 2007, 01:11 PM)

Now that I've got your attention: no, this isn't an OO question. Consider a VI that has a required input. If I then drop that VI (child) into another VI (parent), create a control that wires into the required input of the subVI and then put that control on the parent's connector pane, should the parent's connector pane node become required?

I would say no. There are plenty of cases where the parent VI could put an acceptable default for the control, which didn't need to be wired. Take VISA Configure Serial Port as an example. (That VI uses a property node, which can basically be treaded as a subVI with required inputs.) The Configure VI has many default values which usually don't need to be changed.

Link to comment

QUOTE(Justin Goeres @ Nov 8 2007, 05:32 AM)

...I can't say for sure how often I want those parent inputs to be Required. I'd guess it's more than 50% of the time, but I dunno if it's as high as 75%. The other 25-50% of the time, I probably want them not to be Required. :)

In the words of all 2 years old: "But whhhyyyyy?" As I said, it's philopsphical: what use cases exist when you don't want a subVI's requiredness to propagate to a calling VI's requiredness? What I'm talking about is a subVI that's in a VI that will ultimately be used as a subVI.

Link to comment

QUOTE(crelf @ Nov 7 2007, 11:16 PM)

3. If it's required, then the 'requiredness' attribute propagates upward until it's satisfied (that means keep on going up until there's an explicit non-default data source).

Would you then want the 'requiredness' attribute propagate into two inputs of the parent VI, if the input into child is calculated out of those, as well?

I hope this sentence makes any sense!?! This is the first time I try to philosophize in english :unsure:

Link to comment

QUOTE(crelf @ Nov 7 2007, 04:16 PM)

Whilst I appreciate the sentiment, gimme a use case!

Open TCP/IP prim has a required "port" input. But the VI for connecting to the web has an optional input for "port" -- it defaults to port 80. You can still provide a port, but in that case, most of the time the default is fine.

So use case is anytime a generic API is used in a specific context, there may be a 90% use case for the specific case, but there's no such for the general case. So you make it optional in specific and required in generic.

Link to comment

QUOTE(Aristos Queue @ Nov 8 2007, 02:00 PM)

Open TCP/IP prim has a required "port" input... So use case is anytime a generic API is used in a specific context, there may be a 90% use case for the specific case, but there's no such for the general case.

Right - that's exactly what I was looking for - thanks.

Link to comment

QUOTE(crelf @ Nov 7 2007, 01:11 PM)

Now that I've got your attention: no, this isn't an OO question. Consider a VI that has a required input. If I then drop that VI (child) into another VI (parent), create a control that wires into the required input of the subVI and then put that control on the parent's connector pane, should the parent's connector pane node become required?

A is required, should B be automatically required too?

I would have to say that the parent will never adopt the better practices of the child as the parent will see the innovative things that the children do as cute and truly excessive as all parents know everything and need to never adapt and grow and change. That would be just silly. Heck, if a parent actually changed because of the child... shit... the universe would swallow itself whole. No.... no.... it's much better if the natural order stays the same and the world can only get better by waiting for the old generations to die off and let the new generations fix their mistakes and eventurally not change for the following generation.

..... i have issues

Link to comment

QUOTE(Norm Kirchner @ Nov 8 2007, 02:46 PM)

No.... no.... it's much better if the natural order stays the same and the world can only get better by waiting for the old generations to die off and let the new generations fix their mistakes and eventurally not change for the following generation.

You're soooooo needy.

Link to comment

QUOTE(neB @ Nov 9 2007, 03:41 AM)

That's what the hippies said and look at the mess we are in now that they are in charge

Oooooooooo - I wanted a philisophical discussion, but didn't quite expect this! :D Maybe we should move that one to the lounge in its own thread?

Link to comment

QUOTE(Norm Kirchner @ Nov 8 2007, 05:46 AM)

I would have to say that the parent will never adopt the better practices of the child as the parent will see the innovative things that the children do as cute and truly excessive as all parents know everything and need to never adapt and grow and change. That would be just silly. Heck, if a parent actually changed because of the child... shit... the universe would swallow itself whole. No.... no.... it's much better if the natural order stays the same and the world can only get better by waiting for the old generations to die off and let the new generations fix their mistakes and eventurally not change for the following generation.

..... i have issues

You have Issues? To me sounds like you have KIDS!!!

Shane.

Link to comment

QUOTE(shoneill @ Nov 9 2007, 07:04 AM)

Same thing.

QUOTE(Jim Kring @ Nov 9 2007, 04:45 AM)

What you're talking about is akin to dynamic type propagation...

It is in the sense of the propagation, but not the typelessness (is that a word?) What I'm interested in hearing is input on an even-more strictly typed type.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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