|
Also you can send a class object as the sender for the processing to interact with.
In your example of the processing of the batch input, the result can be given in the same procedure to the sender to be displayed.
|
|
|
|
|
I'm not sure that I've ever needed to do that other than in cases similar to database connection strings -- like a factory of some sort -- and then XML works. 
@"<options option1='true' option2='foobar' option3='42' />"
Obviously, the problem with "but you have absolutely no clue what these optional parameters are unless you look up the online documentation (if it exists)" is taken to a whole new level. 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I think I have some internal, arbitrary rule that says;
If the parameters are basically unrelated except for being passed to that function, then leave them as individual arguments, well defined by their names.
If the parameters are related, then wrap them in some structure or other.
In other words, I wouldn't wrap parameters in a class or struct just to make the function signature smaller or more legible, but I would do so if it made sense for the parameters to be combined;
The danger of wrapping them is that you replace a long function call with a complex struct creation, to no real advantage - reading a method signature with meaningful argument names is self-documentation; the same method with a single argument called "necessaryInfoToDoTheJob is less descriptive!
|
|
|
|
|
|
You preferred way is also the Windows API one: on MSDN you may find a neat, short page about the function, the big mess being on the passed struct.
Veni, vidi, vici.
|
|
|
|
|
We have been using the struct practice for years, and I am personally strongly in favor of it. I would like to add a few comments/modifications, though:
First, a set of options is not a function declaration issue, but a system data design issue. Two or more functions referring to, say, page layout properties should not declare "their own" parameter structs (possibly overlooking some essential parameter). The set of options affecting page layout, say, is one well defined set for the entirre application (or even more).
Second, you should never slump together completely unrelated options in one struct, even if one function (or even several) inspects them all. One option struct defines page layout parameters, another one typographical characteristics, a third one the current user. So you might end up with "several" (i.e. a few) option parameters, but not a hundred of them. (For all practical purposes, this second point is also a requirement for my first point.)
Third, as software develops, new options will be added. For an exported library function, it must be prepared to handle calls from applications both newer (supplying a larger struct with added and unknown fields) and older (supplying structs with missing fields) applications, and be able to handle them both. So the struct must identify the version. So one of the fields in the option struct is "This is format 3". An alternative is "This struct contains 44 valid bytes of parameters. The very best is to include both: This struct contains 44 bytes of parameters of format 3" - then you can add parameters in format 3 as long as the extensions are fully compatible, and bump the format code only when an incompatible extension is introduced. So the caller must fill in two extra fields, but then again, the same declaration can be used twenty years later. (Don't expect anyone below thirty to see the value of that...)
Another alternativ is of course the Win32 API way: Start with MyFunction. Then, when one option is added, call it MyFunctionEx. After the second extension, make it MyFunctionEx. After extension eight, it is MyFunctionExExExExExExExEx, and so it continues 
|
|
|
|
|
I think it's important that there's an easy way to find which options are defined. I've had issues with Javascript libraries that take an object as a parameter, and expect you to put the right properties in there (the XMLHttpRequest AJAX handler does this iirc). In a statically typed language like C# or Java (or even C, Delphi, C++ etc), it makes sense to use a struct or class (using those words in their C# meaning) for groups of parameters with values, and a flagwise enum for those without. If you don't have enums then the old school approach of constants set to the appropriate bit values and using | to combine them is fine too.
The grouping is important, it shouldn't just be public struct StuffUsedByThisFunction, it should have some semantic meaning even outwith the context of the function call.
In dynamic languages the convention seems to be dictionaries with lax validation. I agree that this is often unhelpful, but it's encouraged by the object model in those languages which doesn't really do static declaration of valid members. I've not really worked in those languages enough to have developed a good solution, though.
|
|
|
|
|
|
Into a function? I don't even see how that makes sense.
Generally though I hate dependency injection. It makes it really really hard to find out what type of object you're actually dealing with when you're looking at the code.
|
|
|
|
|
Parameters?
Why not just use Global Variables???
Wait for it...
ROTFLMAO... I did flag this as a JOKE!
That is a HORRIBLE IDEA, for the record...
And for the record, we used a structure, and it worked beautifully.
The tricky part is when you call a function that needs 1 of those parameters... Do you pass the structure, or struct.val3 ? (we based it on the completeness of the function. If we felt it wasn't changing, then we sent as little data as possible, but more than one field meant the structure).
|
|
|
|
|
If the function has "too many" arguments, accept that it's ugly and live with it. Putting them in a struct is just hiding the ugliness and moving the complexity elsewhere, possibly remote from the function call itself. In my mind, it just makes for extra work to understand and maintain.
The optional argument example is a perfect time to use an overload. That way you have a place to document the unique behavior of that variation of the function, and have documented for the next developer which arguments need to be specified as a set.
The struct solution isn't a bad way to hide the problem, although a polymorphic class might be better depending on the needs.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
If the function requires less than 10 arguments, then I let them be as parameters, otherwise, I may start making classes of the one that have something in common and pass that instead.
|
|
|
|
|
A simple object would suffice.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Three of my computers developed completely different problems this morning.
0) The wife's PC exhibits a noise coming from the hard drive.
1) My database server decided that Windows 7 was not longer genuine. I reinstalled Weven and am now in Windows Update hell.
2) My own PC had two fans go out
3) The NIC on my laptop expired - no wifi, no hard-wire. For all intents and purposed, it's practically useless.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Did you feed any of them after midnight?
|
|
|
|
|
... Either that or he got them wet.
|
|
|
|
|
Paul Watt wrote: he got them wet.
Last time I got an electrical device wet, it also acted bizarre.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
John Simmons / outlaw programmer wrote: 0) The wife's PC exhibits a noise coming from the hard drive.
Something is dying... Back it up.
Coincidentally, around this time last year my HDD was dying too 
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
Carl von Clausewitz
Source
|
|
|
|
|
I already did, and went this morning to get a new hard drive. Restoring from the backup as we speak...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
The house transformer is probably not beyond suspicion? (or do you have spike protection)
|
|
|
|
|
I have a whole-house surge suppressor and all six desktop computers are on separate 1100ma UPS devices. Although not out of the question, I suspect a power spike is not the problem.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: I suspect a power spike is not the problem
So you're going with the evil pixies theory, eh? 
Software Zen: delete this;
|
|
|
|
|
Yeah - otherwise, I'd have to go with coincidence, and we all know there's no sch thing. Pixies, on the other hand, are very real.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: Pixies, on the other hand, are very real.
Quite true!
Once the evil pixies move in, the only cure I've found is to shut down everything electronic for a few hours, spend some time relaxing at the shooting range, then come back after they've moved along. It doesn't fix the damage they've already done, but it stops them from committing more mayhem.
Will Rogers never met me.
|
|
|
|
|
The ethics of technology and their application is an oft debated subject. What is ignored is that, without technology, these debates on ethics and morality would not even occur. While it has been cited that our social development has been lacking with regards to our technological development, it is technology, in part, that forces us to develop socially as well. The nature of this tension between an objectifying technology and the subjective issues of ethics and morality is even found in the words we use to describe technologies.
The word "device" has several meanings:
- a thing made for a particular purpose; an invention or contrivance, especially a mechanical or electrical one.
- a plan or scheme for effecting a purpose.
- a crafty scheme; trick.
- a particular word pattern, figure of speech, combination of word sounds, etc., used in a literary work to evoke a desired effect or arouse a desired reaction in the reader: rhetorical devices.
- something elaborately or fancifully designed.
Note how a term we often use when speaking of our technological gadgetry can be both "a thing made for a practical purpose" and "a crafty scheme; trick."
The word "machine" has a similar duality -- "a mechanical apparatus or contrivance", deriving from the Latin machina, again includes the concept of a "trick." The similar word "machination" means "an intrigue, plot, or scheme."
As software engineers, we employ our "craft" in the construction of computer programs, using the definition "an art, trade or occupation requiring special skill", however, the term can also mean "skill in deception and trickery."
Even the word "technology", deriving from the Greek teckhne, "was not concerned with the necessity and eternal a priori truths of the cosmos, nor with the a posteriori contingencies and exigencies of ethics and politics." (http://en.wikipedia.org/wiki/Techne) In this interpretation we see that technology lives outside the realm of truth and ethics. Further "Epistêmê is the Greek word most often translated as knowledge, while technê is translated as either craft or art." (http://plato.stanford.edu/entries/episteme-techne/) Here again we have a reference to "craft."
It is an interesting thing to notice how several of our words, "device", "machine", "craft", and "technology", have a duality to them, indicating both something representing skill and purpose as well as craftiness and trickery. This duality has its parallels and expression in the complexities in determining the ethics of a technology in all its various applications.
-- Reference: In the Belly of the Beast, Technology, Nature, and the Human Prospect, Steve Talbott, 2004, ISBN: 0-9744906-1-X
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
