Ed Leafe wrote:
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?
This was another angle of what I was saying: all of a sudden (as of a few days
ago) we have attribute access to the event data, where before we had to go
through the EventData dict. Now we can do it both ways. This leads to two lines
of thought in my mind:
1) is it such a good idea to have more than one way?
2) if we have attribute access, why not make it property access instead?
I like the attribute access versus EventData, I'm just trying to think ahead a
bit - I never really followed through with the event design stuff, EventData
seemed like a logical place to put all the Event Data at the time, and it still
may be the best way to do it. But if we do end up liking the attribute access,
I'm arguing that we should go with properties instead.
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.
They are listed for us, the developers in one place, and not very consistently.
With props, they get listed both for us the developers as well as those that use
our classes.
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.
Yeah, it is fuzzy. Nothing is black and white. Only accepting properties as
parameters is silly, but being able to accept the property parms is quite
elegant and powerful. Normal arguments can be easily documented in the functions
docstring, but I take your point that this is another case of having to maintain
them separately.
I can't think of any functions or methods that have so many arguments as to
become unwieldy in the same way that the EventData has the potential to.
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 I get the feeling you think it is overkill from our perspective, the Dabo
developer's perspective. Like it will somehow be hard to make the switch to or
hard to maintain, or simply that it will require more lines of code. Is this the
issue or is it that it will somehow be overkill from the POV of our users?
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?
This is how we've been doing it, and I have no issue with that. My issue is that
now we can do it *also* with evt.row. I don't like the *also*; if I had to pick
one or the other I'd probably choose "evt.row"; and if we go with "evt.row", I'd
like it to be "evt.Row".
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
