2009/7/8 Nicolas Cellier <[email protected]>: > Your cents are valuable! > Thanks. Then 1 more cent:
No doubt , this will require deep refactoring/rethinking the Compiler & requestor roles. But it would help greatly in cleaning the Compiler/Parser code from things which related to handle uncertainties, like non-existing selector(s), undefined identifiers, unused temps and so on.. > 2009/7/8 Igor Stasenko <[email protected]>: >> My 2 cents: >> >> compiler should always work together with requestor: >> >> Compiler compile: some thing requestor: aRequestor. >> >> Then it could always ask, aRequestor if its interactive, or not, >> but i think, Compiler could live just well without such knowledge at >> all - each time it needs some extra data - it can simply ask the >> requestor to handle such particular situation, in a fashion like >> following: >> >> Compiler>>compileError: error >> ^ requestor handleError: error ifUnhandled: [ error signal ] >> >> all we need is just carefully establish protocol between Compiler and >> requestor object, so then making interactive/non-interactive/partly >> interactive will be completely independant from Compiler. >> >> 2009/7/7 Stéphane Ducasse <[email protected]>: >>> Hi Pavel >>> >>>> Hi, >>>> >>>> every UIManager may have its own preference about this behaviour >>>> (for example the dummy ui manager has no user input). It is cleaner >>>> solution than to set interactivity for every Compiler instance or >>>> for the Compiler class. >>> >>> In fact I have the impression that this is the same pattern than with >>> preference class. >>> We are now making sure that the Preference layer can be remove by >>> removing references from within the package to the Preference >>> class and we turn into a flow from the preference class to push value >>> to the tools default value. >>> >>> Similarly we prefer that the UIManager pushes information to the >>> compiler and not that the compiler rely on >>> UIManager. I would like to think about a Compiler been able to run >>> standalone without UI. >>> >>> Now we could have >>> >>> UIManager>> setUpForNonInteraction >>> >>> Compiler setInNonInteractiveMode >>> ,... >>> other class >>> >>> and Compiler code >>> referring to itself (its value for non interaction) >>> >>> This way we could even remove completely the UIManager. >>> >>> Else I think that UIManager will become another huge facade that we >>> cannot remove. >>> >>> >>> >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>>> On Tue, Jul 7, 2009 at 7:22 PM, Stéphane Ducasse <[email protected] >>>> > wrote: >>>> pavel I was wondering why you want to have interactiveParserFor: in >>>> UIManager and not in Compiler? >>>> >>>> May be I missed something but I'm ready to learn. >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote: >>>> >>>> > >>>> > From: Pavel Krivanek <[email protected]> >>>> > Date: July 6, 2009 2:26:56 PM CEDT >>>> > To: stephane ducasse <[email protected]> >>>> > Subject: issue 348 >>>> > >>>> > Hi Stef, >>>> > >>>> > I updated the issue http://code.google.com/p/pharo/issues/detail? >>>> > id=348 >>>> > >>>> > Cheers, >>>> > -- Pavel >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Pharo-project mailing list >>>> > [email protected] >>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
