Ed Leafe wrote:
On Oct 17, 2005, at 6:49 PM, Paul McNett wrote:
Something we need to consider is that we are now inconsistent in
casing: referring to evt.row is more like a property interface and
therefore there's an argument for making it evt.Row instead.
...Perhaps we should consider ditching the EventData dict and
explicitly setting up properties in our dEvent class hierarchy.
I think that's overkill. There is no need for setter functionality,
and all we need for the getter is to get the value.
What do you think of the original issue, that referencing evt.attribute is, from
the user perspective, like referencing evt.Property, and therefore that we
should consider capitalizing the "Property"?
I don't think that we should never be able to reference an
attribute. That seems so Java-like. Properties have their place, but
for things like this, it seems silly to waste time defining all those
properties and accessing their getter methods when we could simply be
accessing their values.
The main benefit to turning attributes into properties, whether settable or not,
is that properties can have docstrings while attributes cannot. I think that
attributes have their place, but in the context of our Dabo framework public
API, I just don't think they belong. Sure, users can set attributes and then use
them (that is one of the key features of Python versus Java, I agree), but
attributes we expose publicly should be props, IMO.
And the only reason this is coming up now is that we are now short-circuiting
EventData with __getattr__(), whereas before we were getting the event data via
keys in the dict.
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
