Generalizing is bad, which is why i didnt agree with the "Singletons are
bad, m'kay" mentality here :)
But yeah, i agree with all your points. In some cases lazy loading makes
sense, in some it doesn't.
Though i'm not sure how concurrency is an issue, Pill Pugh's implementation
is probably the
Not at random ... only when needed.
On Sunday, March 17, 2013 6:33:01 PM UTC+2, G. Blake Meike wrote:
>
>
>
> On Sunday, March 17, 2013 9:09:54 AM UTC-7, Piren wrote:
>>
>> If your application has a singleton that takes 200MB of memory and takes
>> a minute to load (dont ask why :-) ), but is onl
> Lew wrote:
>> The biggest problem I have with singletons is that everyone for some
god-awful reason
>> insists on lazily instantiating them. Why?
>>
>> Lazy instantiation is lazy. What's wrong with non-lazy instantiation?
Then you can use
>> a 'final' reference to the singleton instance that
Delete that run on sentence in the end of the second paragraph, apologies :-)
Kris
On Sun, Mar 17, 2013 at 2:16 PM, Kristopher Micinski
wrote:
> I agree with your assessment, but I've never said singletons are evil.
> I've just said that Java statics require more careful use and are
> frequentl
I agree with your assessment, but I've never said singletons are evil.
I've just said that Java statics require more careful use and are
frequently misused by beginners. For experienced programmers, this
advice is obviously insufficient: since there are times when statics
really do help.
I think
Because if the user doesn't use part of the app then they never pay the penalty.
Kris
On Sun, Mar 17, 2013 at 12:33 PM, G. Blake Meike wrote:
>
>
> On Sunday, March 17, 2013 9:09:54 AM UTC-7, Piren wrote:
>>
>> If your application has a singleton that takes 200MB of memory and takes a
>> minute
On Sunday, March 17, 2013 9:09:54 AM UTC-7, Piren wrote:
>
> If your application has a singleton that takes 200MB of memory and takes a
> minute to load (dont ask why :-) ), but is only needed if you use a
> specific part of the app, why load it on the app load?
Can you suggest a better time?
If your application has a singleton that takes 200MB of memory and takes a
minute to load (dont ask why :-) ), but is only needed if you use a
specific part of the app, why load it on the app load?
On Friday, March 15, 2013 3:29:03 AM UTC+2, Lew wrote:
>
> Kristopher Micinski wrote:
>
>> I gues
Honestly i don't get some of the comments here.
Yeah, a bad programmer that doesn't understand how Java works will fuck up
with Singletons .. but that doesn't mean Singletons are evil. As was
already stated - if they are so evil, why is the Android API using them for
pretty much anything that
@Lew on 3/14: +many Why, oh why, do people insist on lazy initialization?
A lot of the debate about singletons ignores specifics. I bet nobody has a
problem with:
public static final String MY_CONSTANT = "CONSTANT";
That's a singleton. Singletons that are mutable are weirder. Lazily
initia
This is basically my point: I don't believe you should never use them,
it's just that many people present them as an "easy obvious solution"
to something that comes with lots of overhead.
Many times they *can* be replaced by specific components. Sure, there
are counterexamples and optimizations (
I wasn't going to enter back into this discussion because it's one of those
that polarises like checked Exceptions.
I also use singletons, but on a rare and very precise basis. And if you
have mentored as many developers as I have then you will understand why the
default mantra of don't use a s
Ah, I also apologize for my previous (perhaps misleading) line
> I guess the bigger problem that in Android static data members cannot
> be statically checked to be "alive".
By this, I mean that in the standard toolchain (i.e., without static
analysis) you can't statically validate your code uses
On Fri, Mar 15, 2013 at 8:56 AM, Kostya Vasilyev wrote:
>
>
> On Friday, March 15, 2013 5:29:03 AM UTC+4, Lew wrote:
>>
>> Kristopher Micinski wrote:
>>>
>>> I guess the bigger problem that in Android static data members cannot
>>> be statically checked to be "alive". [...]
>
>
> if (gInstance !=
On Fri, Mar 15, 2013 at 5:50 AM, user123 wrote:
> And the possibility that someone can do bad things with the singletons, like
> storing views or other things which can lead to memory leaks is not a reason
> to stop using them. You can do this with any class.
>
Let's take a minute to dissect what
Both mentalities are bad. I would actually venture to say that the
"singletons are evil" mentality is worse, since enthusiasts tend to grow
out of the "singletons are awesome" phase. But if someone believes that all
singletons are always evil, how do you persuade them of the depth of their
erro
On Fri, Mar 15, 2013 at 7:56 AM, Kostya Vasilyev wrote:
> So, don't really understand what all the bashing is about. It's a tool,
> use it correctly, and you'll be fine; use it wrong, and you could end up
> with a sore finger.
Word. The "Singletons are evil, if you use them you're doing somethi
On Friday, March 15, 2013 5:29:03 AM UTC+4, Lew wrote:
>
> Kristopher Micinski wrote:
>
>> I guess the bigger problem that in Android static data members cannot
>> be statically checked to be "alive". [...]
>>
>
if (gInstance != null) not working in Android for some reason?
>
>> Moreover, in
Statics? The state of the singleton is instance, not class based. Besides
of the singleton itself. But it's private. And you access it using
public static void getInstance() {
if (instance == null) {
intance = new Whatever();
}
return instance;
}
If the system destroys the app
Kristopher Micinski wrote:
> I guess the bigger problem that in Android static data members cannot
> be statically checked to be "alive". By this I mean: you should try
> to get as much static checking as possible, and if you're using
> statics you don't have any ability to properly check this
I guess the bigger problem that in Android static data members cannot
be statically checked to be "alive". By this I mean: you should try
to get as much static checking as possible, and if you're using
statics you don't have any ability to properly check this.
Moreover, in Android it's a fact of
I really think everyone should stop using the Android Framework, since
it has more than a handful of singletons.
http://developer.android.com/develop/index.html#q=singleton
This is despite research that conclusively proves singletons causing
baldness in males and infertility in women. Oh the dang
On Thu, Mar 14, 2013 at 7:00 PM, user123 wrote:
> What is the problem with singleton?
http://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil
http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons
And, since they don't seem to emphasize the point qu
What is the problem with singleton?
It works very well. I use it to hold global state, for example,
translations. They are fetched at the start of the app, and updated each
screen launch (if necessary). This holds the translations in memory and I
can get them from any activity using simple meth
> You should access it with a getInstance method which will initialize it if
>> it is null.
>>
> You should initialize the variable in the class initialization and declare
> it 'final'.
>
> There are times when you cannot do this, in which case probably Singleton
> is the wrong choice.
>
> F
bob wrote:
> You are not using the singleton pattern properly.\
>
If you're using the Singleton pattern, you aren't using it correctly.
> You should access it with a getInstance method which will initialize it if
> it is null.
>
You should initialize the variable in the class initialization an
No, no, the question is not about the singleton itself. It's about an
instance variable of the singleton.
Am Montag, 25. Februar 2013 16:36:39 UTC+1 schrieb bob:
>
> You are not using the singleton pattern properly.
>
>
> You should access it with a getInstance method which will initialize it if
You are not using the singleton pattern properly.
You should access it with a getInstance method which will initialize it if
it is null.
On Monday, February 25, 2013 3:52:30 AM UTC-6, user123 wrote:
>
> I have an instance variable in a singleton class which I'm using in all
> the app. It'
28 matches
Mail list logo
