Code completion

Dear OA,
I feel excited now that I know you are incorporating IntelliSense-like
features on Dolphin.
I felt tempted to expose here a proposal about what and how I would
like it to behave.
If you find if useful, feel free to use this in any way you like.  If
not, just ignore it, I won't be offended :o)

1) Scenario: You are in the middle of a method (or any workspace view
for that matter), have typed a couple of chars and press the magic
shortcut invoking the code-completion machinery.  Depending on the
particular abstract-syntax-tree-node type you are on (being an object
identifier, selector name, or whatever), the mechanism should smartly
suggest according to the following criteria:
   a.  It is an object identifier.  Thus the following are valid
options:
      i.   self, super, nil, true, false, thisContext, etc.
      ii.  Parameters
      iii. Temporaries
      iv.  Whether inside a block, block parameters or temporaries
      v.   Globals (including Classes, of course), Class variables and
Pools
      vi.  Instance variables
      vii. Anything I might be missing…
   b.  It is a selector.  It depends on the previous object
identifier:
      i.   A literal.  By simple type inference, the actual selectors
could be brought up
      ii.  self.  Class selectors and superclass chain  (according to
my own experience, a       preference enabling-disabling Object
methods is needed)
      iii. super.  Only selectors in superclass chain
      iv.  Otherwise.  If a type inferencer is available, excellent,
it it's not, then all implemented methods
   c.  More advanced (weird?) suggestions
      i.   Suppose you wrote "self printOn: " and then ask for
suggestions.  We know the actual method that will be executed (or at
least quite likely under normal circumstances, printOn: ).  Now, in
#printOn: declaration we can see aStream as a formal parameter.  Then
we can smartly suggest any identifier whose name is, at a certain
extent, reminiscent of aStream on the calling context.  It is not too
strange  that we have an identifier that matches exactly.
      ii.  The partly written identifier could be a regular expression
      iii. When a completion gets executed, there could be some extra
behavior on certain cases.  For example:
         1. If the completed selector is #ifTrue: or the like, a [
could be added
         2. The cursor could be smartly located after that
      iv. In debuggers, inspectors or workspaces, we may have actual
bindings that will sharpen the selector selection on identifiers
      v.  Lint rules could sharpen the selection on certain cases
      vi. Heuristic or rules based on statistics or usage patterns
could be used for sorting the suggestion list
2) Other useful shortcuts
   a. On a selector, definitions and references directly
   b. On an object identifier, potential Types (Classes for that
matter) based on selector sent to it in the current method

Hope this helps.

Best regards,
Daniel

"Daniel Rozzeta" <[hidden email]> wrote in message
news:[hidden email]...
> Dear OA,
> I feel excited now that I know you are incorporating IntelliSense-like
> features on Dolphin.
> I felt tempted to expose here a proposal about what and how I would
> like it to behave.
> If you find if useful, feel free to use this in any way you like.  If
> not, just ignore it, I won't be offended :o)

I would like to add a few additional suggestions to Daniel's fine
suggestions.  I would like to see an OA integrated code completion tool
support most of what I have in my add-on look up tool (
http://www.mitchellscientific.com/smalltalk/CJDLookUp.htm ).  I don't
necessarily expect that the interface should be like my tool (my interface
could use some improvement).  However I do like the way I can filter methods
based on partial text with or without wild cards, and would hope to see
something similar in the OA tool.  I also find that seeing and filtering by
the class that the method is from to be very useful.  I also like what I
have been able to do when in a Presenter subclass.  The formality of MVP can
offer great hints about type, one can guess the model class based on
defaultModel, and the presenters based on createComponents.  I have found
that this works very well for me in practice with my own code.  Of course it
should also know all types when in the debugger.

It seems that I use my tool for two different reasons.  I sometimes know
exactly what I want to type but use my tool to save typing and typos.  Other
times I use my tool when I am not totally sure what I am looking for but
have a vague idea.  That is when the wild card filtering can come in handy.
If the OA code completion tool can address both areas with good context
based inferencing then I will be very happy.

Basically I am hoping the OA code completion tool will eliminate the need
for my look up tool, which I use a great deal.

Chris