Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nx02.iad01.newshosting.com!newshosting.com!216.196.98.140.MISMATCH!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!y41g2000cwy.googlegroups.com!not-for-mail
From: "Aloha Kakuikanu" <aloha.kakuikanu@yahoo.com>
Newsgroups: comp.databases.theory
Subject: Re: OO solution?
Date: 27 Jun 2006 13:29:50 -0700
Organization: http://groups.google.com
Lines: 23
Message-ID: <1151440190.797741.200140@y41g2000cwy.googlegroups.com>
References: <1151333970.145260.93970@y41g2000cwy.googlegroups.com>
   <1151354414.969989.298900@r2g2000cwb.googlegroups.com>
NNTP-Posting-Host: 148.87.1.172
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1151440195 32574 127.0.0.1 (27 Jun 2006 20:29:55 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 27 Jun 2006 20:29:55 +0000 (UTC)
In-Reply-To: <1151354414.969989.298900@r2g2000cwb.googlegroups.com>
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: y41g2000cwy.googlegroups.com; posting-host=148.87.1.172;
   posting-account=k-eobA0AAAA9lwidAVGnIuLVsDrWtvpn
Xref: dp-news.maxwell.syr.edu comp.databases.theory:42440

kvnkrkptrck@gmail.com wrote:
> In keeping with other discussions in cdt, I can't help but wonder if it
> wouldn't be cleaner to use an OO solution.  Just create a Document
> class, and an abstract Viewer class extended by a Group class and a
> User class.  Each Document object can maintain a list of Viewers which
> can view it.  Each Viewer object can maintain a list of Documents which
> it can view; each Group object can store a list of users that are a
> part of it; applicable monadic properties for User objects is left as
> an exercise.
>
> I'll bet the application code would all but write itself.  Plus, you
> can encapsulate these properties and then expose Document methods of
> canView(Viewer v) or Viewer methods of makeDocumentViewable(Document
> d)...  the cool thing is you can carefully change the underlying
> implementation of such methods without breaking any code that calls
> them.

I must admit I feel like humor impared too. For future can you please
make it little bit more obvious? For example, introduce a
DocumentManager class. Then, Manager'sManager. Then argue that
DocumentPermission is unnecessary and can be handled transparrently via
magic object access keywords ("private", "protected").