Re: Re[2]: (Another) (small) Eu 2.5 feature request.
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 24, 2004
- 477 views
On Thu, 23 Sep 2004 19:02:53 -0700, Derek Parnell <guest at RapidEuphoria.com> wrote: >Well that's one interpretation. I was thinking more along the lines that >an 'object' variable can contain any other datatype. In effect, when >you assign someting to an object, the object 'becomes' the datatype of >the assignment. So if you assign a supplier to Temp then Temp 'becomes' >a supplier struct until you assign something else to Temp. If you assign >a customer to Temp it 'becomes' in effect a customer struct. > I see, yes, that approach would seriously impact performance. However I also believe that if you store a customer into an object, you must be allowed to do rather rude things to it to turn it into a supplier, presumably before storing it back in a supplier variable. <aside, skip this if you like> Just to (needlessly) pick on this particular statement: >This is consistent with the current behaviour of object variables. That is true for the three core datatypes of integer, atom, and sequence. But if you have eg: type hour(integer h) return h>=0 and h<=24 end type hour h h=12 integer i i=12 object o o=h then o holds 12, and, if you code it, hour(o) will return true, just as hour(i) or hour(12) would. But o holds no information whatsoever that the data it contains was ever an hour type, as things stand. Philosophically, I view every variable in Euphoria as an object, with the compiler enforcing type checks on assignment (and no doubt some crafty performance optimisations based on the declared type). </aside> Regards, Pete