What could be the possible reasons (technical/non technical) of not using lots of static functions or variables in a program keeping in mind that Framework by itself has tons of static functions and variables?
-
-
Re: static functions variables
If a method does not refer to any state, then it should probably be static as your making it clear it is not and does not need to be an instance method. This can also be more convenient to program against as you can call the static from anywhere in your app domain and don't need an obj instance first. It can also be a bit ~safer as you can't mistakenly change instance data on the type (unless you get a ref to one and go out of your way to change a field). Instance methods kinda tell you they need to be instance methods when you need to refer to instance state,
--
William Stacey [MVP]
"Pohihihi" <noemail@hotmai l.com> wrote in message news:eKEJnrPLGH A.744@TK2MSFTNG P09.phx.gbl...
What could be the possible reasons (technical/non technical) of not using lots of static functions or variables in a program keeping in mind that Framework by itself has tons of static functions and variables?
-
Re: static functions variables
There are no non-technical reasons. And the question is not exactly
well-put. Static functions and data are tools. Some tools are good for some
things, and others are good for other things. So, rather than asking why not
to use "lots of static functions," you should be asking when to use them,
and when not to. In other words, the real question is, "what are the
characteristics of static functions and data that affect my decision of when
to use them?"
Static data is not threadsafe straight out of the box, if you need to modify
it. It can be modified in a threadsafe way, but it requires a bit more work
to do. Static data is global to your application, which means if you change
it in one place, it changes for everything. This can be either good or bad,
depending upon whether or not you want this to happen. Remember that
encapsulation, one of the pillars of OOP, is there for a purpose. Static
functions are fine, as long as they don't need to work with instance data.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Pohihihi" <noemail@hotmai l.com> wrote in message
news:eKEJnrPLGH A.744@TK2MSFTNG P09.phx.gbl...
What could be the possible reasons (technical/non technical) of not using
lots of static functions or variables in a program keeping in mind that
Framework by itself has tons of static functions and variables?
Comment
-
Re: static functions variables
I guess you are right that question was not explained properly. I understand
the desig part of its use and when to and when not to use. What actually I
should have asked is that if I have lots of static functions/variables then
do thay create any memory problem (eating it all) or any performance issues?
What I understand is that because they are static they are in memory all the
time to server its users thus live all the time in memory.
"Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
news:eERWm$PLGH A.536@TK2MSFTNG P09.phx.gbl...[color=blue]
> There are no non-technical reasons. And the question is not exactly
> well-put. Static functions and data are tools. Some tools are good for
> some things, and others are good for other things. So, rather than asking
> why not to use "lots of static functions," you should be asking when to
> use them, and when not to. In other words, the real question is, "what are
> the characteristics of static functions and data that affect my decision
> of when to use them?"
>
> Static data is not threadsafe straight out of the box, if you need to
> modify it. It can be modified in a threadsafe way, but it requires a bit
> more work to do. Static data is global to your application, which means if
> you change it in one place, it changes for everything. This can be either
> good or bad, depending upon whether or not you want this to happen.
> Remember that encapsulation, one of the pillars of OOP, is there for a
> purpose. Static functions are fine, as long as they don't need to work
> with instance data.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> We got a sick zebra a hat,
> you ultimate tuna.
>
>
> "Pohihihi" <noemail@hotmai l.com> wrote in message
> news:eKEJnrPLGH A.744@TK2MSFTNG P09.phx.gbl...
> What could be the possible reasons (technical/non technical) of not using
> lots of static functions or variables in a program keeping in mind that
> Framework by itself has tons of static functions and variables?
>
>
>[/color]
Comment
-
Re: static functions variables
| Static data is not threadsafe straight out of the box, if you need to
modify
I would add that no var is thread safe - instance or static does not really
matter. If a var is "read-write" by 2 or more threads, it needs some kind
of syncronization.
--wjs
Comment
-
Re: static functions variables
William Stacey [MVP] <william.stacey @gmail.com> wrote:[color=blue]
> | Static data is not threadsafe straight out of the box, if you need to
> modify
>
> I would add that no var is thread safe - instance or static does not really
> matter. If a var is "read-write" by 2 or more threads, it needs some kind
> of syncronization.[/color]
Unless it's got a ThreadStaticAtt ribute :)
--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Comment
-
Re: static functions variables
Jon Skeet [C# MVP] wrote:[color=blue]
> William Stacey [MVP] <william.stacey @gmail.com> wrote:
>[color=green]
>>| Static data is not threadsafe straight out of the box, if you need to
>>modify
>>
>>I would add that no var is thread safe - instance or static does not really
>>matter. If a var is "read-write" by 2 or more threads, it needs some kind
>>of syncronization.[/color]
>
>
> Unless it's got a ThreadStaticAtt ribute :)
>[/color]
To be fair he did say "straight out of the box". Though I didn't get my
box. I downloaded VS... How can it be thread safe if there's no box?
Scott
too early in the morning.
Comment
-
Re: static functions variables
If you got the blue box on a Monday, then I think it is. :)
--
William Stacey [MVP]
Comment
-
Re: static functions variables
Hi Pohihihi,
Actually, static members use *less* memory than instance members, because
they exist at the time the assembly is loaded, and there is only one copy.
There's a bit more mumbo jumbo involved because of the framework, but bottom
line is, they are single instances of data. Still, keep in mind the other
characteristics of static members when making your determination. Sometimes
they are exactly the right tool to use. Sometimes they are exactly the wrong
tool.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.
"Pohihihi" <noemail@hotmai l.com> wrote in message
news:e0O$2ERLGH A.344@TK2MSFTNG P11.phx.gbl...[color=blue]
>I guess you are right that question was not explained properly. I
>understand the desig part of its use and when to and when not to use. What
>actually I should have asked is that if I have lots of static
>functions/variables then do thay create any memory problem (eating it all)
>or any performance issues? What I understand is that because they are
>static they are in memory all the time to server its users thus live all
>the time in memory.
>
>
> "Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
> news:eERWm$PLGH A.536@TK2MSFTNG P09.phx.gbl...[color=green]
>> There are no non-technical reasons. And the question is not exactly
>> well-put. Static functions and data are tools. Some tools are good for
>> some things, and others are good for other things. So, rather than asking
>> why not to use "lots of static functions," you should be asking when to
>> use them, and when not to. In other words, the real question is, "what
>> are the characteristics of static functions and data that affect my
>> decision of when to use them?"
>>
>> Static data is not threadsafe straight out of the box, if you need to
>> modify it. It can be modified in a threadsafe way, but it requires a bit
>> more work to do. Static data is global to your application, which means
>> if you change it in one place, it changes for everything. This can be
>> either good or bad, depending upon whether or not you want this to
>> happen. Remember that encapsulation, one of the pillars of OOP, is there
>> for a purpose. Static functions are fine, as long as they don't need to
>> work with instance data.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> We got a sick zebra a hat,
>> you ultimate tuna.
>>
>>
>> "Pohihihi" <noemail@hotmai l.com> wrote in message
>> news:eKEJnrPLGH A.744@TK2MSFTNG P09.phx.gbl...
>> What could be the possible reasons (technical/non technical) of not using
>> lots of static functions or variables in a program keeping in mind that
>> Framework by itself has tons of static functions and variables?
>>
>>
>>[/color]
>
>[/color]
Comment
-
Re: static functions variables
thanks Kevin, that gives me the right thing I was looking for.
"Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
news:ub7eCWXLGH A.1124@TK2MSFTN GP10.phx.gbl...[color=blue]
> Hi Pohihihi,
>
> Actually, static members use *less* memory than instance members, because
> they exist at the time the assembly is loaded, and there is only one copy.
> There's a bit more mumbo jumbo involved because of the framework, but
> bottom line is, they are single instances of data. Still, keep in mind the
> other characteristics of static members when making your determination.
> Sometimes they are exactly the right tool to use. Sometimes they are
> exactly the wrong tool.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> We got a sick zebra a hat,
> you ultimate tuna.
>
>
> "Pohihihi" <noemail@hotmai l.com> wrote in message
> news:e0O$2ERLGH A.344@TK2MSFTNG P11.phx.gbl...[color=green]
>>I guess you are right that question was not explained properly. I
>>understand the desig part of its use and when to and when not to use. What
>>actually I should have asked is that if I have lots of static
>>functions/variables then do thay create any memory problem (eating it all)
>>or any performance issues? What I understand is that because they are
>>static they are in memory all the time to server its users thus live all
>>the time in memory.
>>
>>
>> "Kevin Spencer" <kevin@DIESPAMM ERSDIEtakempis. com> wrote in message
>> news:eERWm$PLGH A.536@TK2MSFTNG P09.phx.gbl...[color=darkred]
>>> There are no non-technical reasons. And the question is not exactly
>>> well-put. Static functions and data are tools. Some tools are good for
>>> some things, and others are good for other things. So, rather than
>>> asking why not to use "lots of static functions," you should be asking
>>> when to use them, and when not to. In other words, the real question is,
>>> "what are the characteristics of static functions and data that affect
>>> my decision of when to use them?"
>>>
>>> Static data is not threadsafe straight out of the box, if you need to
>>> modify it. It can be modified in a threadsafe way, but it requires a bit
>>> more work to do. Static data is global to your application, which means
>>> if you change it in one place, it changes for everything. This can be
>>> either good or bad, depending upon whether or not you want this to
>>> happen. Remember that encapsulation, one of the pillars of OOP, is there
>>> for a purpose. Static functions are fine, as long as they don't need to
>>> work with instance data.
>>>
>>> --
>>> HTH,
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> .Net Developer
>>> We got a sick zebra a hat,
>>> you ultimate tuna.
>>>
>>>
>>> "Pohihihi" <noemail@hotmai l.com> wrote in message
>>> news:eKEJnrPLGH A.744@TK2MSFTNG P09.phx.gbl...
>>> What could be the possible reasons (technical/non technical) of not
>>> using lots of static functions or variables in a program keeping in mind
>>> that Framework by itself has tons of static functions and variables?
>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]
Comment
Comment