ooc-dev team mailing list archive

[<ndd@xxxxxxxxxx>]

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
me: 

 	*
http://sites.google.com/site/steveyegge2/singleton-considered-stupid
[1]
 	*
http://www.ibm.com/developerworks/webservices/library/co-single.html
[2]
 	*
http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
[3]

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
new()

// -- 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.) 

ndd 

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
stuff. 
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 

Resource
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
imports?

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

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

 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).

 ndd

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

> 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
methods.
 >
 > Foo: cover{
 > doSomeStuff: static func(argument: Int)
 >
}
 >
 > Foo doSomeStuff(10)
 >
 > On Sep 28, 2010, at 1:16 PM, Damian 
wrote:
 >
 >> 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]

     

Links:
------
[1]
http://sites.google.com/site/steveyegge2/singleton-considered-stupid
[2]
http://www.ibm.com/developerworks/webservices/library/co-single.html
[3]
http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
[4]
mailto:ndd@xxxxxxxxxx
[5] mailto:oddity007@xxxxxxxxx
[6]
mailto:damian.pop@xxxxxxxxx
[7] https://launchpad.net/~ooc-dev
[8]
mailto:ooc-dev@xxxxxxxxxxxxxxxxxxx
[9]
https://launchpad.net/~ooc-dev
[10]
https://help.launchpad.net/ListHelp
[11]
https://launchpad.net/~ooc-dev
[12]
mailto:ooc-dev@xxxxxxxxxxxxxxxxxxx
[13]
https://launchpad.net/~ooc-dev
[14] https://help.launchpad.net/ListHelp