State-Changed-From-To: open-suspended State-Changed-By: Manu State-Changed-When: Mon Nov 15 21:49:42 PST 1999 State-Changed-Why: Dear James, Using pure basic types to do `copy' is not really recommended. It is better to use the `:=' operator. There are a few routines that does not work well with expanded type. In the forthcoming 4.5 release, we improved the behavior of most routines applied on basic types, but there are still a few incompatibilities which can be resolved easily by using some other features, like `:=' instead of `copy'. Hope this helps, From: James McKim To: bugs@support.eiffel.com Cc: houman@mstr.rh.edu Subject: Re: Compiler/2156 Date: Tue, 16 Nov 1999 10:11:59 -0500 (EST) > From nobody@support.eiffel.com Tue Nov 16 00:32 EST 1999 "nobody"? :-) > To: jcm@rh.edu > Subject: Compiler/2156 > Content-Type: text > Content-Length: 1370 > X-Status: > X-Lines: 42 > > Synopsis: x.copy(3) results in bus error if x and y are Integers > > State-Changed-From-To: open-suspended > State-Changed-By: Manu > State-Changed-When: Mon Nov 15 21:49:42 PST 1999 > State-Changed-Why: > > Dear James, > > Using pure basic types to do `copy' is not really recommended. It is > better to use the `:=' operator. There are a few routines that does > not work well with expanded type. Manu, Here's the history: A student in Houman Younessi's Object Structures class asked if it would be possible to break information hiding in the following way: Assume that depth : INTEGER is public attribute of STACK, and assume we have a client C that declares and creates an instance of STACK via `stk'. Now it's a compiler error to attempt stk.depth := -71, so we can't break information hiding that way. However, what happens if we try stk.depth.copy( -72 )? It looked to me like this should actually work (I was rather hoping for a compiler error along the lines of "Attempt to write to a read-only object", but I don't know of anything in the language that would actually generate such an error). 'Course what happened is that it bombed at runtime, but only 'cause ISE doesn't handle a.copy(b) the way the language says it should, when `a' is an INTEGER. From a student's point of view this is quite unfortunate. A student views INTEGER as a pretty simple class and `copy' as a pretty basic operation. If you can't do basic operations on simple types, the student pretty quickly loses confidence in the language or at least the vendor. And that's a shame. Best, -- Jim > > In the forthcoming 4.5 release, we improved the behavior of most > routines applied on basic types, but there are still a few > incompatibilities which can be resolved easily by using some other > features, like `:=' instead of `copy'. > > Hope this helps, > > With best regards, > The Customer Support Team > > ------------------------------------------------------------- > Answer prepared by: Emmanuel Stapf > > ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117 > 805-685-1006, fax 805-685-6869, > Customer support: http://support.eiffel.com > Product information: info@eiffel.com > > ------------------------------------------------------------- > To answer this message, use the `reply' button of your mail > tool without changing the `subject' header. > ------------------------------------------------------------- > > *** Check our Web page at http://www.eiffel.com > *** for important information: > > - Lots of practical tips and useful information. > > - New on-line manuals and technology papers. >