two cents and some,
PT, I like your philosophy. You included some info there that made me
happy, such as the idea that implicit handlers represent state for other
parties to latch onto as a design pattern. I'll watch this conversation
with interest.
If there was one thing i could contribute, i would mention that past tense
attribute names clearly show causation, i.e. the event is fired after the
act to give other machinery a chance to respond to that state change.
Attributes that are verbs in the present tense, "start", "enable", or
"open" in my reckoning cause state change merely by setting them. Although
laszlo used to have methods for this state change (the depreciated
setWidth or setVisible, etc) and is still the rule when using objective-c
and cocoa (methods are the only way to cause state change, right down to
changing variables individually), i think the legibility gained when
writing constraints is worth the decoupling of methods from state change.
Taken together, you get the two basic forms:
someobj.setAttribute('start', true)
and
<handler name="onstarted" reference="someobj">
...
</handler>
These two rules do cause extra overhead and it does cause there to be more
attributes for a well formed classes API. OTOH it seems to yield code that
is easier to read and derive meaning from. Laszlo is very minimal in terms
of API and that is to be applauded but it's my opinion that legibility
takes precedence, if the expense of doing so is borne by the API creator
and not the end user. It's also nice to have consistent rules to teach new
programmers! I'd love to see a "naming" section of the developers manual.
And i'd be happy to contribute to it over time.
On Fri, 12 Mar 2010 13:53:44 -0500, P T Withington <[email protected]> wrote:
I think there is also a precedent for attributes that represent state to
be the past participle, such as `enabled`, `loaded`, `inited`, and
`applied`. Because such attributes also have an implicit event
associated, you end up with an event `onenabled` (which is sent whenever
`enabled` changes value), and similar for the others. I think this is
why we have the mish-mash of events in animator. `onstart` and `onstop`
are "pure events", `onpaused` is an implicit event associated with the
`paused` attribute. So there's a conflict between wanting attribute
names to be nouns (so you can't call the attribute `pause`) and not
wanting the event to be in the past tense (so you can't have the event
be named `onapaused`).
Our documentation convention is only to document "pure" events (and not
to document the event that is implicit with every attribute), so the
documentation (as I plan to fix it) for <animatorgroup> will on document
`onstart`, `onrepeat` and `onstop`. `onrepeat` is messy because it
collides with the implicit event that should be associated with the
`repeat` attribute. Per your guideline that attributes should be nouns,
we should probably rename that to `repetitions` to clear up that
conflict.
As to renaming `start` to `autostart` or `autorun`, that's not
completely accurate, because this is an attribute that can be turned on
or off programatically, and it has the effect of stopping (for false) or
re-starting (if true) the animator. It is different from `paused`,
because it starts the animator over from its initial state. I'm leaning
toward using the word `enabled` for this attribute. What do you think?
Gee, I'm starting to agree with Rami's comment that this API is a mess!
The only excuse I can offer is that clearly this was one of the first
API's implemented in OpenLaszlo, and it is simply showing its age.
On 2010-03-10, at 14:53, Norman Klein wrote:
One reason the animator API is overly complex is that "start" is
overloaded.
Attribute names should always be nouns (width, height, opacity, ...)
and never verbs (start, enable, ...). Your earlier statement about
changing its attribute name from "start" to "autostart" or "autorun"
would conform to this noun bias.
In addition, past tense event names shouldn't be used since they
don't provide additional functionality and are inconsistent with
existing present tense event names:"onclick", "onmouseover", ....
Also having a past tense implies a present tense, which if I
understand things correctly doesn't exist -- there aren't separate
"pause" and "paused" states.
Norman Klein
Author: Laszlo in Action
There is no precedent or standard within Laszlo to use past tense with
"on+attribute" events; its "onclick" and not "onclicked". The current
event names are: onstart, onpaused and onstop. To be consistent this
should be changed to: onstart, onpause, and onstop, and this also
results in less changes. I think its a bad idea to use past tense in
the event names.
Events:
It seems it would also be nice if we could have the tense of the
events agree. We currently have `onstart`, `onpaused`, `onstop`. If
we don't use `started` as an attribute, we could make these be
`onstarted`, `onpaused`, and `onstopped`. But perhaps that is going
too far?
Your comments solicited.
