>I don't know if now is the time for it, but we might want to take the opportunity to improve the code of NEC on this.
Good idea, and I think this is probably the patch that should be in Pharo 3.
I hadn’t looked deeper into the problem, just eliminated class references.
>I have the impression the check for the presence of WAHtmlCanvas|WARenderCanvas should actually occur in >NECVarTypeGuesser>>getClassFromTypeSuggestingName:
Yes, I agree. And taking a look at some Seaside code, canvas seems to be an alias for html too.
>Next, frameworks (like Seaside) would need a place to plugin such type-guessing improvements. For that we could add a >dictionary to NECVarTypeGuesser where frameworks can register a 'varname->class' mapping.
That would allow simple mappings from html and canvas to WAHtmlCanvas, yes. Would something more
complex be needed to guess based on the receiver?
>Afaik, a small change that is worthwhile for future code changes and a chance for frameworks to improve the code >completion (I guess this is used for code completion? )
I guess so too...
>But, as I said, we can also take this to Pharo4 if necessary…
AFAIK it’s code most recently handled by Esteban and Marcus. They are on the critical path
to releasing Pharo 3, and this is a design improvement that needs a bit documentation.
On the other hand it has a decent set of tests, so we can just resolve 13063 and open a new
issue to do the design improvement.
>thanks for catching the bug ;-)
Yeah, nice one.