I think you pose some interesting design challenges - but it's worthy of experimentation.
I share Denis' enthusiasm to build something better - but it's true it's not an easy problem space. I'm a big fan of GTInspector, but sometimes I slide across and lose my context (not always, and not for all types of problems). For unique extractions - inlining is a no brainer (it's just like code folding in many editors). For non-unique, maybe something in the gutter might let you easily flip... I don't know, but I'm not convinced our current way is always optimal. Still, the whole moldable idea is to make it easy to experiment - and that's the cool bit. That's where we thrive. Tim Sent from my iPhone > On 26 Aug 2017, at 18:38, Thierry Goubier <thierry.goub...@gmail.com> wrote: > > > > 2017-08-26 15:44 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>: >> No Thierry, Newspeak do not allow it. And it not looks similar to what I >> want. > > Hum, you would still get the same overall approach: editor inside editor (or > view inside view). Now, you can say it is not the same, up to you. > > For me, it has the same effect: the editor isn't in a single place anymore. > You may consider it doesn't matter; IMHO it does matter (and it makes for me > the Newspeak editor slightly less efficient; the same that the Smalltalk > system browser seemed more effective than the Self in-place method edit, for > having used both). > >> >> Now command+click on selector opens implementors window. In past it moved >> browser to single implementor. It was nice and it is how other IDEs are >> working. > > You miss the past behaviour? Why not adding it again? > >> But as Tim notice it always loses context. And it is quite difficult to >> browse long call chain which include many small methods. > > I'm not sure it would solve that one. > > Either it is a long call chain with a fan-out of one, in which case the > developper is creating many useless single line methods because it is "the > right way"(tm), or it has a fan-out greater than one (your typical > polymorphic code) and then each time you open, you have half a dozen > implementors. > > For that, you already have the flow browser. > >> So with new editor command+click will be able expand implementor just in >> place. I think it will be big improvement for IDE. > > As I said, with Calypso and Nautilus handling badly long methods, then a > method inside a method just makes the top level method longer... I'd like to > see you do that on Metacello or SmaCC code, where important methods easily go > over 50 lines before you expand anything. > > I'd say there that the GTInspector approach would work better -> expand on > the right, with the ability to keep two side by side, and overlaid with lines > clearly showing what has been expanded (for that "context" thing). > > Regards, > > Thierry > >> >> 2017-08-26 14:59 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com>: >>> >>> >>> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>: >>>> >>>> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon <tim@testit.works>: >>>>> Denis - that's a very cool idea if I've understood you - expand in the >>>>> source code of the current method, literally inline? So you could scroll >>>>> up and down to view the context as you expand it out? >>>> >>>> Yes, exactly. >>> >>> Then that would look a bit like the NewSpeak code browser, if you would >>> like to try the concept. >>> >>> There are disadvantages to that paradigm. One of those is that the system >>> browser in Pharo is ill-suited to long methods. >>> >>> Thierry >>> >>>> >>>>> One of the complaints around refactoring is that you lose context of >>>>> surrounding code - intelligent in place expansion would be the best of >>>>> both worlds... >>>>> >>>>> Tim >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 26 Aug 2017, at 11:40, Denis Kudriashov <dionisi...@gmail.com> wrote: >>>>>> >>>>>> This is really cool. It opens so many possibilities. >>>>>> >>>>>> I imaging method editor where message sends can be expanded to >>>>>> implementors just in place. >>>>>> >>>>>> 2017-08-26 1:03 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: >>>>>>> Hi, >>>>>>> >>>>>>> We are really pleased to announce another major advancement in the >>>>>>> development of the moldable editor, and most of it was enabled because >>>>>>> of one new feature: expandable elements. We think this will impact >>>>>>> significantly our day to day interactions. >>>>>>> >>>>>>> To exemplify what we mean, we will make use of two more alpha projects >>>>>>> that we did not announce yet: GT Documenter (a set of documentation >>>>>>> tools based on Pillar and GT Examples) and GT Mondrian (the graph >>>>>>> visualization engine), both of which are being implemented in Bloc. >>>>>>> >>>>>>> Please take a look at the following pictures showing the documentation >>>>>>> Pillar file that ships together with GT Mondrian. What stands out are >>>>>>> the two embedded pictures. These are actually not pictures, but >>>>>>> visualizations rendered live during the viewing of the document out of >>>>>>> a referenced GT Example. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Now, GT Examples are likely also new for most people. We introduced >>>>>>> them a couple of years ago based on the original idea of Markus Gaelli. >>>>>>> These are a kind of tests that return an object and that can be built >>>>>>> out of other examples. The nice thing is that they are always >>>>>>> executable and testable. So, of course, if you see the resulting >>>>>>> object, you can also see the code that created it, and if you see the >>>>>>> code, you can even execute it live, right in place (notice the preview >>>>>>> of the second snippet). >>>>>>> >>>>>>> <pillar-mondrian-expanded-preview.png> >>>>>>> >>>>>>> Perhaps the most controversial part of GT Examples is that they offer a >>>>>>> mechanism to define static dependencies via pragmas. Please, let’s >>>>>>> leave this debate to another occasion, but please also notice that >>>>>>> tools can use that static information to unfold the code of the >>>>>>> referenced method (notice the nested code editors). >>>>>>> >>>>>>> A side note: if you look closer at the list with three items at the top >>>>>>> of the Tutorial section, you will notice numbering next to #. That is >>>>>>> actually syntax highlighting and so is the mechanism that embeds the >>>>>>> expandable elements. It’s really cool. >>>>>>> >>>>>>> Taking step back, when we introduced the editor a few weeks ago, we >>>>>>> called it moldable because we said we can make it take different shapes >>>>>>> easily. GT Documenter with everything you see in the above screenshots >>>>>>> has currently ~500 lines of code, and all this while still having an >>>>>>> editor that is highly scalable. >>>>>>> >>>>>>> We think that Bloc and Brick will change dramatically face of Pharo and >>>>>>> now we can start to get a glimpse of what is possible. For example, the >>>>>>> use case presented above is more than a technical tool, and we think >>>>>>> this will change both the way we write documentation and the way we >>>>>>> consume it. >>>>>>> >>>>>>> All these will be presented at ESUG both during presentations and at >>>>>>> the Innovation Awards competition. In the meantime, those that want to >>>>>>> play with it can execute the following in both Pharo 6.1 and Pharo 7.0: >>>>>>> >>>>>>> Iceberg enableMetacelloIntegration: true. >>>>>>> Metacello new >>>>>>> baseline: 'GToolkit'; >>>>>>> repository: 'github://feenkcom/gtoolkit/src'; >>>>>>> load. >>>>>>> >>>>>>> And then inspect: >>>>>>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' >>>>>>> asFileReference >>>>>>> >>>>>>> Cheers, >>>>>>> The feenk team >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.feenk.com >>>>>>> >>>>>>> "Innovation comes in the least expected form. >>>>>>> That is, if it is expected, it already happened." >>>>>>> >>>>>> >>>> >>> >> >
