help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Re: New syntax and the BLOX browser


From: Paolo Bonzini
Subject: [Help-smalltalk] Re: New syntax and the BLOX browser
Date: Tue, 16 Oct 2007 09:44:25 +0200
User-agent: Thunderbird 2.0.0.6 (Macintosh/20070728)

Diego Fernandez wrote:
Hi, I'm new to GNU Smalltalk, and I was trying Blox in the lastest
version of GST (from the devo repository in Arch).

When a method source is displayed the browser shows the "[" "]" used
by the new script syntax.
I like the script syntax, because is nice when writing scripts... but
in the browser I think that is better to display methods without the
"[" "]".

It is intentional, though it does not really work without the patch that Stephen pointed you to (and even with the patch, I haven't tested that particular case).

The problem is that single-method compilation is needed in two cases:

1) in the browser, and there one would like to avoid the brackets

2) when the definition of a class changes, and there you need to recompile exactly what was in the source code (including the brackets).

So, there are two opposing behaviors, both of which may be desirable.

I must say I'm not very motivated to implement this, so unless someone steps forward, you'll have to write brackets in the browser too. :-) On the other hand, it should be possible to "unbracket" the methods when they are chosen and "rebracket" them just before accept. As Stephen hinted, both can be done relatively easily, by creating a parser (CompiledMethod>>#parserClass) and parsing the message pattern.

When unbracketing, you scan to the next token and save its position, then you scan all the method and save the position of the last token, and finally you use copyFrom:to: to remove the brackets.

When rebracketing, you scan to the message pattern, and use copyFrom:to: to split the method in two parts. Then you put them together with brackets around the second part.

Unfortunately, there is no single place in which to do this change, because there is no common for MethodSetBrowser and ClassHierarchyBrowser. So, a first (very much welcome) step would be to refactor these two to have a Browser superclass. If you need help, write here so we can help you and put the result on the wiki (a "GST hacker's guide" is another sorely missing part of the wiki).

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]