- A class rename can be accommodated without really breaking all the apps. A
filter could automatically update the name in all SE source apps. I think that
ISE have taken that approach before. (Also, there are other ways of
accommodating class renaming.)
But it's a pity that the same class name is reused with a different interface in
the first place without first checking what VE, ISE and HA have done already.
This is a sure way to inhibit portability - and you can't blame ISE for that
when they (presumably) were first to come up with an Eiffel LINKED_LIST class
I guess that copyright restrictions at the time preventing the use of ISE's
Linked List interface even if the implementation was clean-roomed. Something
like Sun's Community Source Licensing Principles might be good for Nice and the
language standard. It dictates that interfaces remain in the public domain even
if the implementation is proprietary. See
So, lack of co-operation prevents any standardisation of even such basic library
elements that C++ enjoys with the STL. It's not very encouraging.
> -----Original Message-----[snip]
> From: hutch@... [mailto:hutch@...]On Behalf Of
> Sent: Thursday, 1 July 1999 5:55
> To: roger@...
> Cc: smalleiffel@...
> Subject: Re: LINKED_LIST
> So, it is better to break all the applications written in SE?
- Andrew Reilly wrote:
> As another poster mentioned, mixing the SmallEiffel GC with the(Eiffel) Objects allocated on the Eiffel side are managed by the
> C++ malloc/new is probably a much larger problem. How does this
> work with C code now? (You can tell I haven't actually managed
> to do any significant work in SmallEiffel yet: still collecting
> the bits and reading...)
Objects (actually structures) malloc'ed on the C side have to be freed
on the C side as well .
Olivier ZENDRA E-mail: zendra@...
LORIA - NANCY - FRANCE http://SmallEiffel.loria.fr