From: Helmut B. <hel...@gm...> - 2008-07-29 18:51:45
|
Colin Adams wrote: > 2008/7/29 Simon Hudon <sim...@gm...>: > >> It looks to me that all that talk about mutable/immutable strings resembles >> very much to the (somewhat) new idea about expandedness. It seems that for >> immutable objects, we're just not interested in its value/identity duality >> as is the case for integers for example. So I thought that a simpler design >> would be to have STRING_XX_REF and STRING_XX (value type) in addition to the >> parent class STING_GENERAL. In those classes we could implement all kinds >> of optimization such as representation sharing, copy on write in the case of >> shared representations, etc. >> >> I've tried several times to implement them but EiffelStudio seems to have >> issues with expanded classes containing reference field. If that was to >> work, is there any reason why we should prefer immutable strings to expanded >> strings? >> > > Yes. Performance. > > If you are going to substring an expanded type, then you must get a > new object, and so the character-storage is duplicated (just as in the > current situation). This can cause extereme garbage collection > overhead for string-intensive applications (which is the reason I have > been pushing this issue for over a year). > > Colin, to my understanding you did not respond to Simon's remark. Simon proposed an expanded class with a reference attribute. The reference attribute should point to a shared representation. This has advantages and disadvantages. Garbage collection overhead is (at least a I understood Simon) not a disadvantage of his proposal. By the way, reference attributes in expanded classes are valid Eiffel constructs. They should work fine. What is the problem with reference attributes in expanded classes/types? Regards Helmut http://www.sourceforge.net/projects/tecomp http://tecomp.sourceforge.net |