Hi Zulq,

thank you very much for your work. Let me try to explain what the
DynamicProtocol #required means. The documentation on the class says:
«I contain all selectors you have to implement in order to make your
class concrete». This takes into account:

- #subclassResponsibilites methods
- messages you send but for which there is no implementation (even if
you do not implement a #subclassResponsibility)
- required methods comming from traits.

I think RequiredSelectors does its job well (the algorithm is complex
and is the subject of an scientific article). We probably have to use
it in some way. Maybe we just have to set up an interest on this
class, I don't know.


Good luck

On Feb 7, 2008 12:06 AM, Zulq Alam <me at zulq.net> wrote:
> Apologies for the long post. There have been so many lately. I wanted to
> share my progress and thoughts about dynamic protocol performance.
>
> There are four really troublesome dynamic protocols:
>
>    DPLong          reads all sources
>    DPUncommented   reads all sources
>    DPSupplied      lengthy analysis, no caching
>    DPRequired      lengthy analysis, no caching
>
> When you browse to a class or a browser refreshes, each dynamic protocol
> is (re)calculated to determine whether it should be listed. It is then
> recalculated when selected. If the protocol is cacheable, the cache will
> be used when populated. Refreshes can be triggered by browsing, class
> changes or do-its and print-its (many of these unrelated).
>
> I've uploaded a package to SqueakSource which should help
> (DynamicProtocols-za.69). On the basis that it is better to list an
> empty protocol I allow protocols to define a pain threshold. If the
> target class has more selectors than this pain threshold, the protocol
> is always displayed and only calculated when accessed.
>
> To help determine whether a protocol has been calculated, protocol names
> now include the number of methods they contain, e.g. "-- long (?) --" or
> "-- override (3) --". A "?" means the number of selectors is above the
> pain threshold and the protocol will be calculated on access.
>
> I've also had a stab at the required protocol (the worst offender):
>
> | selectors  |
> selectors := Set new.
> aClass allSuperclasses reverseDo:
>    [:eachSuperclass |
>    eachSuperclass selectorsAndMethodsDo:
>      [:eachSelector :eachMethod |
>      selectors remove: eachSelector ifAbsent: [].
>      eachMethod isRequired
>        ifTrue: [selectors add: eachSelector]]].
> selectors removeAllFoundIn: aClass selectors.
> ^ selectors
>
> This is faster than using Behaviour>>#requiredSelectors but also gives
> completely different results! I have either misunderstood what
> "required" means or something isn't right with one or the other.
>
> For example, "AColorSelectorMorph requiredSelectors" answers 16
> selectors that are not required, many are not even from the same hierarchy.
>
> Anyway, the pain thresholds probably needs some adjustment but it all
> seems useable in my image. I'd be interested to hear how it works for
> others and any comments on changes.
>
> Thanks,
> Zulq.
>
>
>



-- 
Damien Cassou