[self-interest] simplicity

Michael Latta lattam at mac.com
Mon Jun 28 03:20:43 UTC 2004

If I can paraphrase your position:

Reference counting is more deterministic when releasing resources that 
have semantics beyond bits in memory.

I would agree with that statement.

I think you are really arguing for the programer to have more control 
over the systemic decisions made by the VM developer (GC vs. Ref 
Counts, heap vs. stack allocation, etc).

I would agree with that in theory.  In practice having too many knobs 
(look at J2EE) is also a problem.

This seems to again suggest some type of Aspect type system to apply 
flexible design decisions throughout a system is of interest, and a VM 
that allowed more control over the operation of the application.

Any design decision made by the VM limits the application's flexibility 
and ability to address design issues.  As such the hard-coded design 
decisions should be kept as few as possible.  This is where the Java VM 
has made some big mistakes.


On Jun 27, 2004, at 2:53 PM, Ian Woollard wrote:

> Chandrasekhar Ramakrishnan wrote:
> Yes, but you could also do this:
> class ZooWriter {
>         FileHandle mFH;
> public:
>         void write_zoo() {
>                 mFH = open("/adir/afile", open);
>                 mFH << "I went to the zoo";
>         }
>         void after_writing_zoo_write_home() {
>                 mFH << ". Then I went home";
>         }
>         void essay() {
>                 write_zoo();
>                 after_writing_zoo_write_home();
>         }
> }
> And then you'll have a problem.
>  Well, because you've chosen to declare mFH in the object, it doesn't 
> go out of scope in the above. However, if ZooWriter goes out of scope 
> then it could (if you make appropriate changes to ZooWriter).
> (Aside -- how would you implement the open function described in your
> example?
>  It's essentially optional reference counting; so returning it would 
> increment it an extra time before it goes out of scope since that is a 
> reference too.
>  Instead of creating an open function, I would have given
> FileHandle a two argument constructor and written FileHandle f("path",
> open), but there's always more I can learn about C++.)
>  It was dog C++ code; I was just trying to express the idea of closing 
> a resource automagically; I think you got the idea.
>  My C++ is rusty, but IRC you can do it either way, but your way is 
> cleaner.
> But this is unreliable in Java/Self/Smalltalk- you don't know when the
> GC will get around to release it. I consider this to be a bug in these
> languages.
> Yes, but if your runtime uses a two-space GC implementation and
> collects recently allocated objects more frequently, the file handle
> will be closed reasonably soon,
>  That's a big if; and GC rate depends on the rate of object creation 
> in many cases. A generational technique is more popular these days I 
> think, and can result in quite a long delay in the worst case.
>  and you get the added bonus that the
> example I provided won't cause any problems.
>  I'm not saying that finalisation functions are forbidden! I'm just 
> saying that in quite a lot of cases this is a very useful pattern; and 
> I've used it extensively in the past. No design patterns are 
> universally applicable.
>  And although it is essentially the same technique as reference 
> counting pointers, I don't see this as being a bottleneck on 
> efficiency- it's unlikely that the reference/dereference calls would 
> be as frequent.
> - sekhar
> --
> C. Ramakrishnan        cramakrishnan at acm.org
> Yahoo! Groups Links
> 	• 	To visit your group on the web, go to:
> http://groups.yahoo.com/group/self-interest/
> 	• 	 To unsubscribe from this group, send an email to:
> self-interest-unsubscribe at yahoogroups.com
> 	• 	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of 
> Service.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4217 bytes
Desc: not available
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20040627/bc9a9e2d/attachment.bin>

More information about the Self-interest mailing list