Best Practice Question - How do you prefer to pass a bunch of options to a function?
-
You do understand that we are working with event driven programming right? The entire inner working of the object programming model has a point of origin and the event that triggered it. You should always be making your code generic as it can be understood by everything, and your procedure should be tread safe - which means everything you need should be passed as a parameter.
Colborne_Greg wrote:
You do understand that we are working with event driven programming right?
That's a very narrow point of view, focused on one technology set. At no stage did Marc state he was asking about an event. And while there is a point of origin, there's no guarantee that he is responding to an event - you may have noticed that Marc was talking in a generic sense, hence the reason he mentioned ROR. So, in the case of doing something like processing a batch input on a file, forcing the programming model to use an event signature doesn't really make sense.
Colborne_Greg wrote:
You should always be making your code generic as it can be understood by everything, and your procedure should be tread safe - which means everything you need should be passed as a parameter.
And that is why my response, at the top of this thread, stated that I would normally wrap things up into an object.
-
Colborne_Greg wrote:
You do understand that we are working with event driven programming right?
That's a very narrow point of view, focused on one technology set. At no stage did Marc state he was asking about an event. And while there is a point of origin, there's no guarantee that he is responding to an event - you may have noticed that Marc was talking in a generic sense, hence the reason he mentioned ROR. So, in the case of doing something like processing a batch input on a file, forcing the programming model to use an event signature doesn't really make sense.
Colborne_Greg wrote:
You should always be making your code generic as it can be understood by everything, and your procedure should be tread safe - which means everything you need should be passed as a parameter.
And that is why my response, at the top of this thread, stated that I would normally wrap things up into an object.
When the procedure was called is an event when the processing a batch input on a file BOF reached and EOF reached are events. Everything is an event, and inheriting from eventargs allows your code to be repurposed everywhere, and when all your delegates have the same signature you wont get held back when you want to dive deeper into generics.
-
Colborne_Greg wrote:
You do understand that we are working with event driven programming right?
That's a very narrow point of view, focused on one technology set. At no stage did Marc state he was asking about an event. And while there is a point of origin, there's no guarantee that he is responding to an event - you may have noticed that Marc was talking in a generic sense, hence the reason he mentioned ROR. So, in the case of doing something like processing a batch input on a file, forcing the programming model to use an event signature doesn't really make sense.
Colborne_Greg wrote:
You should always be making your code generic as it can be understood by everything, and your procedure should be tread safe - which means everything you need should be passed as a parameter.
And that is why my response, at the top of this thread, stated that I would normally wrap things up into an object.
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.
-
When the procedure was called is an event when the processing a batch input on a file BOF reached and EOF reached are events. Everything is an event, and inheriting from eventargs allows your code to be repurposed everywhere, and when all your delegates have the same signature you wont get held back when you want to dive deeper into generics.
Seriously, everything isn't an event. Not all environments are event based, and for those that are, creating events for things that don't need to be events is an unnecessary overhead. We might as well stop now because I'm not going to convince you and you aren't going to convince me.
-
Seriously, everything isn't an event. Not all environments are event based, and for those that are, creating events for things that don't need to be events is an unnecessary overhead. We might as well stop now because I'm not going to convince you and you aren't going to convince me.
You are thinking to hard. Kiss - keep it simple stupid. Everything is an event whether you are programming with events, responding to events, or looking for events in code via a conditional statement, an event is a English word that gives abstract context to meaning. Its like arguing that a date/time, or decimal is not a string - well yes those are strings and are processed differently, which is the opposite to generics - inherit from eventargs whether or not you are responding to an actual event so that all your delegates have the same signature, then when you get into the thinking of what an actual event is your code will become cleaner.
-
You are thinking to hard. Kiss - keep it simple stupid. Everything is an event whether you are programming with events, responding to events, or looking for events in code via a conditional statement, an event is a English word that gives abstract context to meaning. Its like arguing that a date/time, or decimal is not a string - well yes those are strings and are processed differently, which is the opposite to generics - inherit from eventargs whether or not you are responding to an actual event so that all your delegates have the same signature, then when you get into the thinking of what an actual event is your code will become cleaner.
I suppose the difference between you and me is that I have experience in none event driven systems, as well as in none .NET platforms so my first instinct is not to always make things an event. They aren't suitable for every platform. So perhaps you need to think a little harder and get out of the .NET bubble. It'll open your mind.
-
Key-Value Options: Let's say you have a function that can take a bunch of options for how to build something, say some auto-generated HTML, when passing them as parameters is just too cumbersome? Personally, I would just put all the options into a struct and pass an instance of the struct into the function. The nice thing about that is, the struct (or class, if you wish) documents all the possible options. Now, in the land of Ruby, I see everybody everywhere using key-value pairs associated with symbols, like this:
{option1: true, option2: "foobar", option3: 42}Now of course the symbols usually have some intelligent meaning, but you have absolutely no clue what these optional parameters are unless you look up the online documentation (if it exists) and then can be sprawled across numerous pages on the website. And worse, in the Ruby code, these options are of course usually tested using the symbol:if opts[:option1] ... endsuch that, if you mistype the "key" (symbol), nothing is going to complain to you, unless the programmer checks the option list for unknown options, which I have NEVER seen done. Now, there's lots of alternatives in the, say, C# world. Your function can take a variable number of parameters. You can require that the caller provides a callback for resolving options. You can just put everything into the function's parameter list, and so forth. Or, like Rubyists, you can pass in a dictionary or some such thing of options. Valueless Options (aka flags): So far, the above discussion deals with options that have associated values. There is also the issue of "valueless" options -- if the "key" is present, then the option is "selected." One of the most common ways of passing in valueless options to a function in most languages is of course with an enum, especially when you can use the "or" operator to combine multiple valueless options. Now, mind you, in Ruby, there is no concept of an enum, which is a serious drawback in my opinion. But I'm curious what people consider to be their own best practice. MarcIf 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.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
I suppose the difference between you and me is that I have experience in none event driven systems, as well as in none .NET platforms so my first instinct is not to always make things an event. They aren't suitable for every platform. So perhaps you need to think a little harder and get out of the .NET bubble. It'll open your mind.
-_- I am a cobol programmer, I also started my statement with... when dealing with Microsoft related products which is the dot net bubble...
-
I believe that strictly speaking, you do NOT have optional parameter in .NET. You have it in C#. But it is handled solely by the compiler, at compile time. Sort of synthetic sugar. (Or sugar-free, since we are talking about parameters who are not there in the source code.) In the .NET assembly, noone can tell whether the value specified as default in the function declaration was really defaulted or specified explicitly by the caller.
Good point. Although .NET has sort of become a synonym for C# and VB and they both support it :) Strictly speaking you're right though.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
I would have to go with wrapping the parameters in a struct/class. That way, I can put all sorts of validation in there that gives the object some context.
Also protects you when you have to add another option.
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
-
Key-Value Options: Let's say you have a function that can take a bunch of options for how to build something, say some auto-generated HTML, when passing them as parameters is just too cumbersome? Personally, I would just put all the options into a struct and pass an instance of the struct into the function. The nice thing about that is, the struct (or class, if you wish) documents all the possible options. Now, in the land of Ruby, I see everybody everywhere using key-value pairs associated with symbols, like this:
{option1: true, option2: "foobar", option3: 42}Now of course the symbols usually have some intelligent meaning, but you have absolutely no clue what these optional parameters are unless you look up the online documentation (if it exists) and then can be sprawled across numerous pages on the website. And worse, in the Ruby code, these options are of course usually tested using the symbol:if opts[:option1] ... endsuch that, if you mistype the "key" (symbol), nothing is going to complain to you, unless the programmer checks the option list for unknown options, which I have NEVER seen done. Now, there's lots of alternatives in the, say, C# world. Your function can take a variable number of parameters. You can require that the caller provides a callback for resolving options. You can just put everything into the function's parameter list, and so forth. Or, like Rubyists, you can pass in a dictionary or some such thing of options. Valueless Options (aka flags): So far, the above discussion deals with options that have associated values. There is also the issue of "valueless" options -- if the "key" is present, then the option is "selected." One of the most common ways of passing in valueless options to a function in most languages is of course with an enum, especially when you can use the "or" operator to combine multiple valueless options. Now, mind you, in Ruby, there is no concept of an enum, which is a serious drawback in my opinion. But I'm curious what people consider to be their own best practice. Marc
