Re: time / update problem

Le Jeudi 14 Juillet 2005 23:49, Raphael Mack a écrit :
> Hi,
>
> Am Donnerstag, den 14.07.2005, 23:26 +0200 schrieb Frederic Merizen:
> > TIME is an expanded class, so the qualified call 'c.never' returns a copy
> > of the attribute. The call to 'update' only updates the copy.
> >
> > I'd say there's a dessign lesson here: "think twice before creating
> > mutable expanded classes" (such as TIME - but I do not intend to
> > specifically criticize TIME here. There may well be good reasons for this
> > choice in the case of TIME - maybe a performance tradeoff. I don't know
> > for sure, I wasn't on the team yet when that class was written.)
>
> ok, but then what is the sense of allowing such a call? x.y.cmd will
> never yield s.th. useful if y is expanded, isn't it?

mmh, how about this ?
	x.y.print_on(std_output)

> Or can one construct an example where the expanded class Y has a
> reference to some object c and cmd modifies c?

yes, that's definitely possible

> mhh. x.y returns a copy that is fine, but why isn't a command x.y.cmd
> executed "on" the attribute in x?

I don't know for sure (I wasn't around when the language was designed either). 
Maybe they wanted

	x.y.cmd

to behave consistently with

	local_y := x.y
	local_y.cmd

> ok, that would enable to "write" to 
> the attribute of x from outside, what is forbidden for good reasons. But
> since the expanded class Y is mutable, that seems exactly what is want.

Well, yeah. I'd guess most experienced Eiffel programmers were bitten by that 
behaviour at least once. Don't really know what to say here.