Hi Tim, 2017-08-26 23:27 GMT+02:00 Tim Mackinnon <tim@testit.works>:
> 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). > I think you may be on the key issue, the loss of context when navigating through the code. In the 90's, that was called the 'lost in hyperspace' problem linked with hypertexts and hypermedia. I'm not sure it was ever resolved (I stopped following that research community during my PhD), apart from considering that google solved it for the web. At least, this would be the choice made by Newspeak: consider that the code is like the web, and build a system web browser. > > 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. > Agreed. I have changed the way I code to reduce the context needed to understand it. > > Still, the whole moldable idea is to make it easy to experiment - and > that's the cool bit. That's where we thrive. > Smalltalk has allways been open to that sort of experiment. The moldable bit may make it easier, or at least not more complex than it was when Smalltalk systems were a lot smaller. Now, is that moldable implementation really that free, or has it sacrificed certain freedoms to make moldable things easier? Regards, Thierry > > 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." >>>>>> >>>>>> >>>>> >>>> >>> >> >
