On Aug 21, 6:28 pm, Jarek Foksa wrote:
> Here are the rules that I'm following when choosing names for
> custom events (those are by no means standard):
> - event name should start with 'on' word
My initial feeling, when starting down this road some years ago, was
that an 'on' prefix would make ev
Based on all related answers, I decided to agree with Laurie's definition:
...the event naming should be based on the semantics of what happened, not
> on what module noticed it happen
Therefore, started to name my events with a more descriptive way, like this:
- onServiceDrop
- onService
On 2011-08-22, at 1:38 PM, Scott Sauyet wrote:
> Laurie Harper wrote:
>> If you start using 'internal' identifiers in your events, your
>> sandbox is leaking. Why go to the trouble of hiding the object
>> types and decoupling everything if you're just going to couple
>> it up again by exposing impl
Laurie Harper wrote:
> If you start using 'internal' identifiers in your events, your
> sandbox is leaking. Why go to the trouble of hiding the object
> types and decoupling everything if you're just going to couple
> it up again by exposing implementation details in string
> identifiers?
I think
