"Sam, from the context of what I know in non-pollock VW7.1 , I want to unify events and the older change notifications. In 7.0 there was an attempt by triggering events in self changed: however this was backed out again in 7.1. I prefer the more direct event system in most cases and encourage my developers accordingly, but it gets very convoluted when domain models do events but the existing widgets or namely their standard ValueModels don't listen. I'm sure you have considered and come across this issue in Pollock and possibly already commented on (if so I apologize). I'm not yet convinced though the dual hierarchy being encouraged by EventModel is the way to go as there are a lot of existing subclasses in ValueModel to duplicate and I don't see mixins anywhere on the VW radar. "
First a comment on failed attempt of unification in 7.0. We added code to the update: mechanism in 7.0 that looked at this aspect, and if it was a symbol, triggered an event with that symbol for that object. The problem turned out to be twofold. The first, and the one that prompted Pollock to NOT use the update/change mechanism at all, is the fact that update/change is very chatty. Because ALL dependents of an object get ALL update messages, without regard to if they are interested in them or not, AND because of the nature of how they are used in Wrapper, setting off a single "self changed: #value", leads to a hell of a lot of messages, most of which are actually ignored. Worse, most of those that aren't specifically ignored, are ignored in effect, because they in turn do a "self changed:" themselves, just leading to more noise. The bottom line was that a LOT of trigger events were triggered, and because no one in the base system was using them, they were TOTALLY ignored. So, the effect of this was that we just added to the chatter.
Second, it turns out that unless your object is using a local event handlers, the lookup into the global backstop EventHandlers takes some time. Now, we have gone a long way in 7.2 to make that faster, but in 7 and 7.1, the lookups weren't coded for speed. In fact, doing a failed lookup in the global EventHandler was adding something like 10x to the execution of the update: message! That slowed the system down beyond any acceptable measure. Worsened even more so because of the chatter that the change/update system caused itself.
Of course, in Pollock, the EventModel system does have it's own local event handlers, and since it doesn't itself participate in update/change, is a very quiet and fast system (particularly with our speedups in 7.2).
But that's not just the final answer. First, there aren't a lot of subclasses of ValueModel. In fact there are only 12 in the base system. Some are no longer required in Pollock (TextCollector), and the rest are adaptors which have a two classes in Pollock that replace them all (AccessAdaptor and BufferedAccessAdaptor). We'll be able to translate your uses of these adaptors to the Pollock equivalents with our translation tools.
Now, you may be thinking instead of the MANY subclasses of Model.
Subclasses of Model are simply classes which have a local dependents instance variable, same as the EventModel has a local event handlers. So, let's look at all of these. First, there is the ApplicationModel. Yes there are HUNDREDS of subclasses of these, but without exception they are User Interface things, and well, Pollock has this in the UserInterface class. We will be providing tools to translate your ApplicationModel code into UserInterface code.
Then there a bunch of system models, a dozen or so, such as DebuggerService and ChangeSet. These will of course have to be converted for use to Pollock, but that's our problem, not yours.
Finally, there are the selection models. These were used in the GUI, but are no longer needed as part of Pollock. Again, for these, we'll be able to translate these to the appropriate Pollockisms for you with our translation utilities.
So the only thing which will be left out are your specific subclasses of Model and or ValueModel. For your Model objects, again, we'll probably have tools to help you move them over to be ModelValue subclasses. For your own subclasses of ValueModel... well, yes, there you'll be on your own.
Of course, you'll probably figure out how to translate your ValueModel subclasses yourself in about a day. But if you can't, well, that's why you buy support with your license to VisualWorks. We also sell services, and I'm sure we'd be glad to contract with you to help with your porting to Pollock.
Don't let Cincom know that I'm saying this but: You probably won't need to PAY for that kind of simple help, will you?
Previous Topic
