Re: Re[2]: (Another) (small) Eu 2.5 feature request.

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu