Yes. I think that it would be great to have a smart student working on a SummerTalk Project on that.
Stef On Jul 8, 2009, at 1:22 AM, Igor Stasenko wrote: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
