On Oct 18, 2005, at 10:22 AM, Paul McNett wrote:
I didn't even know that was possible until this discussion.
It just became possible a few days ago. You don't remember saying:
Yes, that's the discussion to which I was referring. I thought
that this was around for awhile, though, based on yours and Adi posts.
And now that it is possible, it seems more simple to say:
gridRow = evt.row
instead of:
gridRow = evt.EventData["row"]
Yes, but then why not simply add it as an attribute in the first
place? IOW, instead of populating an EventData dict when an event is
created, why not set attributes directly? Instead of populating
self._eventData in the dEvents class, why not just set attributes, if
we don't need to deal with the EventData property?
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.
That's a good point. Remember, though, that each of these
values is set in the __init__() for the UI, so they are already
listed in one place.
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?!
I'm just taking your reasoning to the next logical step. Why
have method calls that can contain both regular named parameters and
named Property parameters? That's no more or less confusing than
referencing attributes and properties of an object.
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.
Of course.
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.
And it seems like overkill 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.
Would you feel the same if it was evt.EventData["row"]? That's
two lower case items and a title case item. Do you really think that
Python users are going to get confused with something like this?
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
