[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: setter problem
- To: email@example.com (Andrew LM Shalit)
- Subject: Re: setter problem
- From: firstname.lastname@example.org
- Date: Mon, 26 Oct 92 14:22:36 PST
- Cc: email@example.com, Jeff Dalton <firstname.lastname@example.org>, email@example.com
- In-reply-to: Your message of Mon, 26 Oct 92 16:48:02 -0500. <9210262141.AA07299@cambridge.apple.com>
Okay, so (setter m) is actually a variable in and of itself. But that
doesn't make sense with (set! (m foo) item). Is there similar macro
magic going on here? Is this syntax also under redesign consideration?
According to Andrew LM Shalit, Dylan does things this way so that
the getter and the setter can be exported (or not) separately.
I could also see that there might be performance hits in building
'setter' into a dispatcher.
But all of a sudden, Dylan doesn't seem as elegant as I originally
thought it was. Isn't there a way of turning setter into a dispatcher
that at compile-time can be, but may not be optimized out of existence?
(-Since I assume some fancy optimizations happen with the general
method dispatcher anyway?) Assuming this can be done, can't the
export information that can't be compiled out be assimilated into
P.S. Although, I've never used T, I had heard of T's setter
function and I did originally think that Dylan's was the same