← Back to team overview

ooc-dev team mailing list archive

Re: Singletons?


Ahah, but that's where we disagree. Believe me, I fully grasp the
seduction potential of singletons, and I'm guilty of having used them
much in the past.. 

Others have said it before, and much better than


Concerning your example, what if you want several resource managers
that have different options? (ie. memory quotas/timeout before freeing
old unreferenced stuff, different loading paths, maybe disable the cache
completely one of the managers for debugging? different levels of
logging and destination of logging message, etc.) 

When your brain
thinks of singletons, it automatically becomes stupid - and misses
opportunities to make your code more flexible, easier to maintain and
debug, and more natural. 

Passing around an instance isn't *that* bad
of an idea, and storing an instance in an instance variable isn't too
bad either. 

If you really really want to emulate the Scala way I guess
this would work marvelously: 

// -- cut

_MySingle: class {
instance vars
 init: func {
 // initialize

MySingle := _MySingle

// -- cut 

Then, MySingle would be the instance, as in Scala,
and nobody in his right mine will go instanciate _MySingle directly (the
underscore is usually a convention of "don't touch or I'll bite your
balls off" in ooc land - aka "pseudo-protected". It's not impossible
that at some point in the future, a compiler switch is implemented to
enforce the encapsulation of such attributes.) 


On Wed, 29 Sep
2010 17:13:08 -0300, Damian  wrote:  

Well, I don't know; it's one of
the features I love from scala. 
I find singletons useful *a lot* of
times. It's just an object that there will be only one instance in the
app and that can be accessed from anywhere in the code.  
To me it's
useful for example to create a manager of resources, that has internal
cache, and where I can ask for a resource and the manager will look for
it in the cache or load it, process it, and chache it, and that kind of
I hate the pattern as you describe it too, because MySingle
should be the instance, not a class, and I should be abble to do
something like: 

Resources getResource("nana") 

instead of 

getInstance() getResource("nana") 

I think that the namespaced imports
are more suitable... Though I don't like it too much to be honest. But
well, ooc is not 100% object oriented and maybe it's just that I'm not
used to that.  

By the way, is there any documentation about namespaced

On Wed, Sep 29, 2010 at 3:58 PM,  wrote:

 Well singletons are
more than namespaces, although I kinda hate this
 pattern, here it

 you can choose to implement 'new' as your get method:

MySingle: class {

 _instance := static alloc() as This
 new: static
func -> This { _instance }


 if you dislike this (because 'new'
sortof implies that it's a new
 instance..) just use 'get' instead of
'new', there's not really a
 convention here yet

 also, there's no
special syntax like Scala's object: I actually dislike
 this bit of
Scala's syntax, it's mostly useful for the main class in
 Scala anyway..
(correct me if I'm wrong).


 On Wed, 29 Sep 2010 14:33:01 -0400,

> Easy: Don't.
 > ooc != Java
 > If you want a
namespace sort of effect, just use namespaced imports:
 > import
Source/Path/Foo into Foo
 > Foo doSomeStuff(10)
 > If you can't
use namespaced imports (for one-file-monsters), use a
 > cover's static
 > Foo: cover{
 > doSomeStuff: static func(argument: Int)
 > Foo doSomeStuff(10)
 > On Sep 28, 2010, at 1:16 PM, Damian 
 >> What's the proper or preferred way to create a singleton
in ooc? Is > there something specific to do so? (like 'object' in scala,
for > example)
 >> Thanks!
 >> Mailing list:
https://launchpad.net/~ooc-dev [7]
 >> Post to :
ooc-dev@xxxxxxxxxxxxxxxxxxx [8]
 >> Unsubscribe :
https://launchpad.net/~ooc-dev [9]
 >> More help :
https://help.launchpad.net/ListHelp [10]
 > Mailing list:
https://launchpad.net/~ooc-dev [11]
 > Post to :
ooc-dev@xxxxxxxxxxxxxxxxxxx [12]
 > Unsubscribe :
https://launchpad.net/~ooc-dev [13]
 > More help :
https://help.launchpad.net/ListHelp [14]


[5] mailto:oddity007@xxxxxxxxx
[7] https://launchpad.net/~ooc-dev
[14] https://help.launchpad.net/ListHelp