[self-interest] simplicity

[Ian Woollard]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20040627/7763d2d0/attachment.html>