On 2010-02-28 18:42:50 -0500, Pelle Månsson <pelle.mans...@gmail.com> said:
On 02/28/2010 10:01 PM, Michel Fortin wrote:
If you want a rationale, I think it'd be fine to say that attributes are
things you can ignore because they only have a restrictive effect on the
semantics (the definition you said you invented). Then mention there is
an exception: @property.
Sorry if I go on and miss the point some more, but I dislike this a
lot. That's imposing restrictions on future @attributes. Like, for
example, @memoized. Or something like that. @traced, maybe.
If I'm not mistaken about your intention, making a function @memoized
wouldn't change its semantics. It'd change how it is optimized, but
both from the caller perspective and for the one who write the
function's implementation, it's totally transparent. Well, not exactly:
it puts some restrictions for the function's body, same as purity I
believe.
So someone who just want to understand how a program works can ignore
@memoized when looking at it (at least until he wants to look at the
optimizations).
The difference with @property is that it changes how you call it, it's
not a transparent change at all.
This is me envisioning user-defined @attributes, really. They can
reduce boilerplate and increase flexibility in cases like @traced.
Not sure what you mean about @traced. If you mean that any call to a
function is logged somewhere, then I don't see that as a change in
semantics neither for the caller nor for the one who write the
function, so it'd have no problem having that as an attribute.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
