On 3 January 2012 16:24, Sean P. DeNigris <[email protected]> wrote: > > Igor Stasenko wrote >> >> as well as it could serve as a source of confusion, because you using >> same protocol for different purposes >> in two different frameworks. >> A medal always has two sides :) >> >>> Consistency makes frameworks easy to understand and use. >> > > I think having the two frameworks have the same API would be much easier > than if they were almost the same. And I don't think that similarity would > cause confusion - quite the opposite. When working with a different > framework, I've already shifted my context to the abstractions of that > framework. However, my fingers naturally want to > type/select-from-autocomplete/etc. the exact same things they've done > before, and I don't have to look at a browser to see "how was that selector > slightly different from the other one?" >
exactly. just few days ago, we were hacking new events model with Stef. and i wrongly implemented #handleEvent: which is sent by InputEventFetcher and actually Sensor should just put an event into own queue, because this message were send in fetcher process. while event handling happens inside ui process. with announcements i had to rename #handles: to #handlesAnnouncement: first because if i would not do so, it would be not possible to migrate code (because handles: expect announcement class as argument, and if i change the sender, it will break it) or if i change all implementors of #handles: i will also break it because announcers are still sending this message with wrong argument. well, maybe it is not a big deal. and we could just use #handles: but imo #handlesAnnouncement: looks more explicit (now you have less chances to be confused with the role or receiver - an announcement filter and role of argument - an announced object) > -- > View this message in context: > http://forum.world.st/About-announcements-tp4253255p4257251.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.
