R help - Mar 2012 - Singleton pattern

Hi all,

I know it may not have much sense thinking about a Singleton Pattern in an
R application which doesn't use any OOP facilities, however I'm curious
to
know if anybody faced the same issue. I've been googling but using
"singleton pattern" as a key word leads to typical OOP languages like
Java
or C++ among others.

So my problem is that I'd like to ensure some very big objects aren't
copied again and again in some other variables. In the worst case I'll
check all code by myself to ensure it but in this case the application
won't force programmers to take it in consideration which is what I am
really looking for.

Any advice will be highly appreciated :P

Thanks!
-- 
*David Cassany Viladomat
Software Developer
Transmural Biote**ch S.L*

	[[alternative HTML version deleted]]

David Cassany <david.cassany <at> transmuralbiotech.com> writes:
> 
> Hi all,
> 
> I know it may not have much sense thinking about a Singleton Pattern in an
> R application which doesn't use any OOP facilities, however I'm
curious to
> know if anybody faced the same issue. I've been googling but using
> "singleton pattern" as a key word leads to typical OOP languages
like Java
> or C++ among others.
> 
While it isn't too hard to implement the Singleton pattern using reference 
classes, I would think for what you want to do the memoise package can 
be used. Create a wrapper function to return the objects and the cached
value will be returned each time.

> So my problem is that I'd like to ensure some very big objects
aren't
> copied again and again in some other variables. In the worst case I'll
> check all code by myself to ensure it but in this case the application
> won't force programmers to take it in consideration which is what I am
> really looking for.
> 
> Any advice will be highly appreciated :P
> 
> Thanks!

Since no one else has "bit", I'll take a stab.  I'm an
experienced R person, but I've recently been teaching myself objective-c and
I've been using singletons quite a bit (and mis-using them quite a bit!). 
Not a computer scientist at all.  You've been warned.

I don't think there is a comparable concept in R.  You do have a choice of
S3 or S4 classes for your object orientation in R.  S3 is very loose in that you
can add to S3 objects readily and abuse them a lot.  There really is no checking
of them unless you implement it manually.  S4 objects are much
"tighter" and they are less readily modified and are self-checking (I
know some will complain about this characterization but  it's approximately
correct).  So perhaps you want an S4 object so it's less likely to get
mangled, but I doubt there is a way to prevent users from copying it, which
would be more along the lines of a singleton.

You can google the archives for some great discussions of S3 vs S4 if that
sounds interesting.

Bryan

***********
Bryan Hanson
Professor of Chemistry & Biochemistry
DePauw University

On Mar 16, 2012, at 7:47 AM, David Cassany wrote:
> Hi all,
> 
> I know it may not have much sense thinking about a Singleton Pattern in an
> R application which doesn't use any OOP facilities, however I'm
curious to
> know if anybody faced the same issue. I've been googling but using
> "singleton pattern" as a key word leads to typical OOP languages
like Java
> or C++ among others.
> 
> So my problem is that I'd like to ensure some very big objects
aren't
> copied again and again in some other variables. In the worst case I'll
> check all code by myself to ensure it but in this case the application
> won't force programmers to take it in consideration which is what I am
> really looking for.
> 
> Any advice will be highly appreciated :P
> 
> Thanks!
> -- 
> *David Cassany Viladomat
> Software Developer
> Transmural Biote**ch S.L*
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.