On 11/04/2016 03:50 AM, Norbert Hartl wrote:
Am 04.11.2016 um 07:53 schrieb Nicolas Cellier
<[email protected]
<mailto:[email protected]>>:
2016-11-04 1:54 GMT+01:00 John Brant <[email protected]
<mailto:[email protected]>>:
> On Nov 3, 2016, at 4:03 PM, stepharo <[email protected]
<mailto:[email protected]>> wrote:
>>>> Furthermore, if comments are nodes, how do they affect all of the code
rewriting and validation that is part of the RB and its rewrite tools
>>> With comments cannot act as nullobjects for such operation?
>> Yes, someone could spend time making all of this work with the existing
code. However, why not fix the real problem in that comments and methods should not
be a single string, but rather objects.
>
> Marcus did that during his phd and he blew up memory. So after we got
a guy that worked on tree compression but he never finished.
> Because this is the part that makes all these ideas flying or not.
From what I remember, ASTs are roughly 10x the size of the code
string. I’m not suggesting holding on to them in the image when
they can be loaded/built from a file like the method sources
currently are. Instead, we can associate a comment/annotation to a
particular node in the AST without having to keep the AST around.
For example, we could say that some comment is associated to the
4th node visited from the standard AST traversal. We don’t need to
keep the AST around since we can recreate it and the 4th node
visited will be the same.
John Brant
But this vision is a bit static. Code is living. Shall these
annotations be lost on next refactoring? Or are we going to diff the
two AST and salvage as many annotations as we can? Or are we going to
keep an history of these comments in the versioning system?
+1
It's only static if you do a poor implementation. The refactorings
already operate on the AST level so we don't need any AST diffing for
them. We would need to update the rewriter to update this information
for nodes that get replaced. This updating would likely need the help of
the annotation objects since some annotations might not want to be
copied to the replaced node, and others (e.g., comments) would need to
be copied.
The editor will need to be changed to display these annotations/comments
so we can also change it to keep track of the rearrangement of the
nodes. That leaves custom tools that use the compile:* methods. These
will need to be updated if they want to generate code with proper
annotations/comments.
Of course, all of these will need to be stored where they can be
versioned. Currently, we store some of the method properties outside of
a method body:
!SomeClass methodsFor: 'some category' stamp: 'SomeAuthor 1/1/1111
11:11:11'!
The additional properties could be store similarly. The ANSI standard
already defines the SIF format which contains annotations that can be
added to filed-out objects.
John Brant
