Ed Leafe wrote:
On Oct 17, 2005, at 8:17 PM, Paul McNett wrote:
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 see the significance. But then again, I've always accessed
these things via the EventData dict, since that's where Dabo stores
that information. I never even thought of accessing the wxEvent stuff
via __getattr__(); I didn't even know that was possible until this
discussion.
It just became possible a few days ago. You don't remember saying:
"""
I understand that part. My question is why we are addressing the uiEvent
object from Dabo code. That's wx-specific, and Dabo code should not be relying
on wx-specific implementations.
I would be in favor of something like:
def __getattr__(self, att):
if self._eventData.has_key(att):
ret = self._eventData[att]
"""
("dEvent Patch", 10/11/2005)
And now that it is possible, it seems more simple to say:
gridRow = evt.row
instead of:
gridRow = evt.EventData["row"]
The main benefit to turning attributes into properties, whether
settable or not, is that properties can have docstrings while
attributes cannot.
OK, but how critical is it that we have a docstring for stuff like
'altDown' and 'shiftDown'? You mean that if we simply list the
attributes available for a given event type, people won't know what
they mean, but that the docstrings will take care of that?
It isn't necessarily an issue of people not knowing what something means, but
more an issue of knowing that something is even available to begin with. Props
are kind of self-documenting, in that if it's a prop it gets documented for free
(whether or not it has a docstring). If it is an attribute or a key in a dict,
we have to remember to make a list of them somewhere and to maintain that list
separately, while if it's a prop we'll already have that list.
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 then I guess that the next logical step is to not have any
function parameters that are not properties either, eh?
Huh?!
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.
Like I said, I was perfectly happy accessing the info I needed via
the EventData dict. I don't think that requiring this was so bad, but
hey, if we can make it simpler by letting people do evt.shiftDown vs.
evt.EventData["shiftDown"], then cool, go for it. But requiring no
attribute access at all? I think that that's rather draconian.
I think it would be draconian to deny users being able to set their own
attributes. And it would even be draconian to go out of our way to keep people
from accessing our attributes instead of the properties. But making a consistent
property interface to everything that is public seems like a good plan to me,
for the reasons I've mentioned before. But the real thing that started this line
of thought wasn't to propertyize the event data, but it was wondering about the
lower-casing of the event data attributes when normal props are title case -
from the outside looking in there really isn't enough difference between
attributes and properties for us to explain why it is lower case here versus
title case there.
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
