Evaluating Dolphin

> I don't really understand what you mean by creating methods "from usage".
> Can you elaborate please?

Probably the auto-creation of undefined methods is meant. In ST requires
that either the receiver can be determined or must be specified in an
additional step. Only works well when you have instant parsing. E.g.
self makeStuff: aValue.
Place cursor on selector and press (e.g.) Alt+Enter. Select "Create method"
in appearing popup.
To accomplish this in Dolphin, the old method should be marked as
uncompilable instead of a force
to copy to clipboard or discard (maybe a good example of supportive instead
of controlling behaviour).

> As I say, I'm not really sure what you are getting at by "usage" here,
This is somewhat undetermined in ST, I agree. In Java, the receiver/object
of a message/method call is always determined at compile time. The only
glitch can be an interface is the formal receiver. In this case, IDEA
renames all instance's methods as well.

> Incidentally if you have installed PL2, you can easily view a list of all
> accelerator keys in the browsers by choosing the 'Key Bindings' command on
> the common Help menu.

Ah, great. I was afraid I had to wait until D6 :-)

> I read about, and it seems like a neat idea, so I implemented it (see
> attached). I've used Ctrl+Y simply because its available and Ctrl+W isn't.
> You'll have to open a new browser to get the accelerator recognised. Also
> the patch relies on a method installed by PL2.

Now this IS something!! I would wish that the selectors can be selected,
too. Now the surrounding expression is immediately selected when cursor is
on selectors.
Also, by all means, is it possible to enable this in workspaces???


> It isn't quite as useful in D5 as it might be, because it doesn't work in
modified source text, but if
> in some future version the methods were parsed dynamically...

Hey Blair, this sounds indeed interesting...

Ciao

...Jochen

"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]...
> > I don't really understand what you mean by creating methods "from
usage".
> > Can you elaborate please?
>
> Probably the auto-creation of undefined methods is meant. In ST requires
> that either the receiver can be determined or must be specified in an
> additional step. Only works well when you have instant parsing. E.g.
> self makeStuff: aValue.
> Place cursor on selector and press (e.g.) Alt+Enter. Select "Create
method"
> in appearing popup.
> To accomplish this in Dolphin, the old method should be marked as
> uncompilable instead of a force
> to copy to clipboard or discard (maybe a good example of supportive
instead
> of controlling behaviour).

I see what you mean by that, and can see how that would be nice, especially
in a language which doesn't encourage debugging of partially complete
programs. In Smalltalk, where I can freely run and debug partially complete
programs, I'd often achieve the same effect in Smalltalk by coding in the
debugger. In other words I'd run the method in the certain knowledge that
bits are missing, perhaps driving it from a test or by performing some
command in the application window I've got open, and then going into the
debugger, and defining the method in there. I like that style because a) it
fits the test driven style of first writing the test and then fleshing out
only what is needed to pass the tests, b) I don't have to write too much
code before I start testing something, c) the Debugger tends to name the
arguments correctly in the usual Smalltalk pattern, and  d) I find it easier
to write the method in a concrete context.

>
> > As I say, I'm not really sure what you are getting at by "usage" here,
> This is somewhat undetermined in ST, I agree. In Java, the receiver/object
> of a message/method call is always determined at compile time. The only
> glitch can be an interface is the formal receiver. In this case, IDEA
> renames all instance's methods as well.

Certainly you're likely to be able to do a better job on method renames in
Java because the static type information allows the refactoring engine to
easily identify which methods actually should be renamed. In practice this
is less of a problem in classic Smalltalk than it first appears to be
because Smalltalk programmers soon begin to realise that overuse of common
selectors such as #add: makes important code reading tools like
references/definitions (or senders/implementors) significantly less
effective.  Maybe more could be done with type inferencing, but I would have
to defer to John Brant or Don Roberts for an opinion on that one.

>
> > Incidentally if you have installed PL2, you can easily view a list of
all
> > accelerator keys in the browsers by choosing the 'Key Bindings' command
on
> > the common Help menu.
>
> Ah, great. I was afraid I had to wait until D6 :-)
>
> > I read about, and it seems like a neat idea, so I implemented it (see
> > attached). I've used Ctrl+Y simply because its available and Ctrl+W
isn't.
> > You'll have to open a new browser to get the accelerator recognised.
Also
> > the patch relies on a method installed by PL2.
>
> Now this IS something!! I would wish that the selectors can be selected,
> too. Now the surrounding expression is immediately selected when cursor is
> on selectors.

Well that's because the syntactic unit the message send, not the message. It
would only really make sense to be able to select unary or selectors anyway,
because of the way keywords and arguments are interspersed in Smalltalk. In
other words I can't really see a way to do that consistently.

I suppose the question is, why do you want to do that? If it's because you
need to select the selector in order to initiate a refactoring, or perhaps
kick off a browse references/definitions, then that doesn't really need a
selection, and for the next version you just need to place the cursor over
the selector somewhere. I thought about including this change in the last
patch, but it was a bit to entangled in other stuff. Maybe I'll have a look
again for PL4.

BTW: You can improve the behaviour of my little method by changing the
#ifTrue: test at the end to a #whileTrue:. This is needed so that it can
keep widening out in some circumstances. I've attached a new version below,
which will also work for DSE/DVE users, as it includes the #selectedNode
method that was not in PL2 for those versions.

> Also, by all means, is it possible to enable this in workspaces???

Not at present because that would require some sort of dynamic compilation
of the content. Since workspaces may often contain multiple snippets of code
that are not actually valid when viewed as a whole anyway, I'm not sure how
that would work out. As an aside I really would discourage you from writing
too much code in workspaces.

Regards

Blair
-----------------------
!MethodBrowser methodsFor!

widenSourceSelection
 | node |
 node := self selectedNode.
 node isNil
  ifTrue:
   ["Normally we'd just disable the command, but to avoid patch to
#queryCommand: ..."
   Sound warningBeep.
   ^self].
 [sourcePresenter selectionRange = node sourceInterval] whileTrue:
   [node := node parent.
   node isNil
    ifTrue:
     [Sound warningBeep.
     ^self]].
 sourcePresenter selectionRange: node sourceInterval!

selectedNode
 | range |
 range := sourcePresenter selectionRange.
 range isEmpty ifTrue: [range := range start to: range start].
 ^self parseTree ifNotNil:
   [:tree |
   | node |
   node := tree whichNodeIsContainedBy: range.
   node isNil ifTrue: [node := tree bestNodeFor: range].
   node]!

additionalAccelerators
 "Answer a collection of additional accelerator definitions for commands not
on the
 menu bar of the receiver's view(s)."

 ^#(#(#widenSourceSelection 'Ctrl+Y'))! !
!MethodBrowser categoriesFor: #additionalAccelerators!constants!public! !
!MethodBrowser categoriesFor: #selectedNode!accessing!private! !
!MethodBrowser categoriesFor: #widenSourceSelection!commands!private! !

"Blair McGlashan" <[hidden email]> wrote in message
news:b334s0$1i941s$[hidden email]... one
> wants to be able to extract a constant to either a class or pool
variable].
>
> Of these, the first is not a refactoring at all. In Dolphin one would
> achieve this by saving a class definition, and then a single drag & drop
> operation to copy all methods to the new class. Frankly I'm not sure I
would
> want to encourage this sort of cut and paste coding by making it any
easier.

Technically speaking, copying a class is a refactoring as long as the class
doesn't conflict with some existing class. Anyway, you give the reason why I
haven't added it to the RB. It is already fairly easy, and I don't know if
making copying a class easier would be a "good thing".


> The second is similar in concept to 'Extract Temporary', but to (in
> Smalltalk terminology) a class or instance variable. While not as useful
as
> Extract Temporary, there have been circumstances I can recall where I've
> wanted to do just this. However, since Smalltalk doesn't have the concept
of
> initializers or constructors it might be difficult to implement some of
the
> possibilities in a correct way. The simplest case of extracting to a new
> instance variable with assignment of the value at the extract point seems
> fairly straightforward, being effectively an 'Extract to Temporary'
followed
> by a 'Convert to Instance Variable'. Certainly, worth putting on the list
> though.

Yes, I just do the extract to temporary and then convert it to an instance
variable.


> Extract Superclass would appear to be a composite of 'Create subclass',
and
> a sequence of 'Pull Up instance/class variable' and 'Push Up method'
> refactorings. The only really difficulty with providing this refactoring
is
> an appropriate UI that allows one to select all the pieces one wants to
> extract out. If there were sufficient demand we could consider doing it.

I never implemented it because making the choices in a dialog box seems just
as complex as making the individual choices on the methods/variables.
Furthermore, you probably want to look at the code before you move it up.


> 'Replace Inheritance with Delegation' is an interesting one, that needs
some
> thought. I don't have a particular opinion on its usefulness.

We had this one a long time ago. Before the RB, we had the refactory tool
(1993-95). It had a convert superclass to component "refactoring". It was
removed because this is very hard refactoring to get right. You have to
prove that the "self" (or this in Java) doesn't escape from the superclass.
For example, consider:
    ClassA
        method
            Transcript print: self

        printOn: aStream
            aStream nextPutAll: 'ClassA'

    ClassB (superclass ClassA)
        method
            Transcript show: 'a '.
            super method

        printOn: aStream
            aStream nextPutAll: 'ClassB'

You cannot convert ClassB to use delegation unless you copy ClassA's #method
implementation into ClassB's #method. If you don't, then it will print "a
ClassA" to the transcript instead of "a ClassB". While it is difficult to
prove that such a transformation is a "refactoring", it might be a good one
to add. As we built the RB, we started adding transformations that weren't
strictly refactorings but were useful transformations.


> 'Replate temp with query' is effectively a repeated sequence of 'Extract
> Methods', since after the first 'Extract Method' the refactory engine
would
> identify and use the same method. It would be nice to automate it,
however,
> as I do find myself doing this quite a lot.

It shouldn't be that difficult to change the RB to do that. It will require
prompting the user for each code segment though.


> Now looking at it the other way around, I identified 8 refactorings in
> Dolphin that (judging purely from the web page) are not supported by IDEA:
>
> 1) (Safe) Remove Variable

Safe Delete appears to do the same thing.


> 2) (Safe) Add Variable
> 3) Protect/Concrete Variable

This is a composite refactoring of inline method and safe remove method.

> 4) Convert class to Sibling (not explained on John Brant's page, this
> effectively pushes down a superclass to be a sibling of its subclasses all
> under a new abstract superclass, leaving all common methods in the new
> superclass)

You may be able to use their extract superclass, replace inheritance with
delegation, push up var/method, and safe delete refactorings to accomplish
this (depending on how good the replace inheritance with delegation is).


This is a composite refactoring (extract method, move to component, &
inline/remove the delegating method).


> 2) Inline Method (from Component). The inverse of (1), this allows to
inline
> implementation from another class.
> 3) Create Accessors. Since this is a part of Abstract Variable (called
> Encapsulate field in IDEA) I imagine this must be supported.
> 4) Move Method to Component. The IDEA page mentions a Move Members
> refactoring, which might well do this, but there is no further information
> about it.

It appears that they only move static members.


> In summary, there are some refactorings supported by both environments
that
> are not supported by the other. In fact there are rather more missing from
> IDEA, but its arguable as to which has the more comprehensive refactoring
> support. Both support the core refactorings that one uses all the time
like
> Extract Temporary, and Extract Method (does IDEA support Extract to
> Component and the reverse inline, I hope so, because that would be a
fairly
> major omission if not).
>
> All of this also leaves out the fact that the Refactoring Engine
underlying
> the bindings in the Dolphin IDE is a powerful and flexible code rewriting
> tool that can be scripted to perform custom code rewrites. There is no UI
> onto this in Dolphin 5 (there will be in the next release), but the
original
> Refactoring Browser has one called the Rewrite Tool. Do you have access to
> this kind of machinery in IDEA? I couldn't find any mention of it.

Java has parse tree rewriting tools
(http://www.cin.ufpe.br/~phmb/papers/JaTSALinguagemSBLP2001.pdf), but I
don't know of any other IDE besides the RB that has rewrites available to
the user. While most users don't need them, they can be extremely useful in
some cases. Will Loew-Blosser had an experience report at OOPSLA that showed
how useful they can be
(http://csc.noctrl.edu/f/opdyke/OOPSLA2002/Papers/TransformDataLayer.pdf).
He was to perform 16,000 method changes with less than 30 bugs introduced.
He estimated that it only took 3% of the time it would have taken if he was
performing it by hand.


>I read about, and it seems like a neat idea, so I implemented it (see
>attached). I've used Ctrl+Y simply because its available and Ctrl+W isn't.
>You'll have to open a new browser to get the accelerator recognised. Also
>the patch relies on a method installed by PL2. It isn't quite as useful in
>D5 as it might be, because it doesn't work in modified source text, but if
>in some future version the methods were parsed dynamically...

You can use SmaCC to parse methods dynamically. I used it to create a code
highlighter for VW(http://wiki.cs.uiuc.edu/VisualWorks/RB+Code+Highlighter).
It has some error recovery features, so it can cope with syntax errors.


John Brant

Jochen,
especially
> in a language which doesn't encourage debugging of partially complete
> programs. In Smalltalk, where I can freely run and debug partially
complete
> programs, I'd often achieve the same effect in Smalltalk by coding in the
> debugger. In other words I'd run the method in the certain knowledge that
> bits are missing, perhaps driving it from a test or by performing some
> command in the application window I've got open, and then going into the
> debugger, and defining the method in there. I like that style because a)
it
> fits the test driven style of first writing the test and then fleshing out
> only what is needed to pass the tests, b) I don't have to write too much
> code before I start testing something, c) the Debugger tends to name the
> arguments correctly in the usual Smalltalk pattern, and  d) I find it
easier
> to write the method in a concrete context.

I just thought I'd mention here, in case it wasn't clear, that Blair is
referring to the Debug/Implement In command in the Dolphin debugger that is
enabled when it is brought up on any message not understood exception. This
will automatically implement a method stub in the chosen class with (often)
appropriate parameter names. You just have to flesh out the method contents,
compile it and then hit F5 to continue. As Blair says, this isn't just for
fixing the odd method that you've forgotten to implement; you can start with
a blank class and use it to flesh out all of the methods one by one as the
program (or SUnit test) is running. Does IDEA have this ability?

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Jochen,

> This means that IDE's like IDEA are not text editors any more, but
> intelligent realtime coding assistants.
> I will say IDEA from now on but all major Java IDEs are going in this
> direction.
> I know that you are thinking in this direction as I read about your AIBO
> assistant.

Yes. While the AIBO Pair Programmer was a bit of a gimmick the underlying
coding assistant is not. For those who haven't seen the demo, this Code
Mentor will be available in D6 and adds almost instantaneous feedback on
methods that have just been compiled (I doubt it can be made fast enough to
work as you type unfortunately). The feedback includes reports on bugs,
possible bugs and coding style issues. The 11th slide in the following
presentation shows what the Code Mentor looks like:

http://www.object.arts.dial.pipex.com/oopsla/XP-BestFriend.pdf

We also tacked on the ability to attach a little "agent" cartoon character
to the mentor. This again seems like a gimmick but we found while playing
around with it that having this working in the background an verbally
reporting errors/style issues is less distracting than having to every do
often focus on a "happy face" icon while working. We grew to quite like it,
although I suspect it won't be to everyone's tastes.

> the IDEA approach is a bit different. To me it was actually a bit of a
> surprise that the static typers were first in implementing this
> consequently. What is done is that the entire code base (!) is parsed,
> analyzed and put into an internal database.

Hmm... the fact that IDEA needs to do this seems to me indicative of the
poor state of Java's reflection interfaces. Such a database is there in
Smalltalk, of course, but it just happens to be the objects (and classes and
methods) themselves.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Wow, this has been a really helpful thread, even though several people
have questioned the OP's intentions.  I've learned a lot from reading
the thread.

A couple of features that I think would be more "supportive" of the
developer (as several posters have mentioned).  I've mentioned most or
all of these before, but they seem appropriate again.  I looked into
implementing some of them, and got lost - I'm still pretty new to
Smalltalk in general, and Dolphin in particular:

1. I love the coding in the debugger support (though I probably don't
use it nearly as much as I could).  There's a related use case that gets
me every time, though.  When I write a test first, I often haven't yet
defined the class I want to test.  So, I'll make a FooTest class, add a
testBar method to it and start it like this:

testBar
    | foo |
    foo := Foo new.
    self assert: foo baz.

At this point, I can't accept the method because class Foo isn't
defined, and I can't leave the method editor without losing my changes.
  I generally keep a second browser open just for this situation, so I
can go create the missing class so that I can save my new test method.

VisualWorks Smalltalk has a feature (that needs a couple of extra
features, in my opinion).  When saving a method, if there are symbols
that it doesn't recognize, it prompts you what to do about them.  The
most common situation for me would be this:

I type:

testBar
    foo := Foo new.
    self assert: foo baz.

It wouldn't recognize "foo", and would prompt me whether it should be an
temporary or an instance variable (VW gives the temporary choice and a
few others - it really needs the instance variable choice).  It also
wouldn't recognize "Foo".  VW lets you leave it undeclared and still
save the method.  That would be an improvement over Dolphin's current
behavior.  What I'd really like is a choice to define a new class that
would pop up the Create Class... dialog.

Other choices might make sense here, but those are the three that I'd
use the most.

With this, I could type the method above, automatically make foo a
temporary or instance variable and make Foo a new class.  Then I could
run my test, get a dnu: on baz, use Implement in... in the debugger, and
be off and running.  That would be awesome.

Blair or Andy (or anyone else, for that matter): if you could give me
some solid pointers on how to go about implementing something like this,
I'd have a go at it.

2. VW has a bunch of keyboard shortcuts for things in method editors and
workspaces.  This is not an exhaustive list, but the ones I remember:

- Ctrl-G for := (G = gets)
- Ctrl-F for ifFalse:
- Ctrl-T for ifTrue:
- Select a block of code and type Esc-<key> and it toggles between
wrapping and unwrapping the selected code with the associated character.
  Key can be:
"
'
(
[

These are incredibly handy things to have.  I tried implementing this
myself, but didn't know how to define the keyboard shortcuts.  Now,
thanks to Blair's patch in this thread, I know how to do that, so I'm
going to have another go.  If I get it to work, I'll post back here.

Thanks,
Randy
--
Randy Coulman
NOTE: Reply-to: address is spam-guarded.  Reassemble the following to
reply directly:
rvcoulman at acm dot org

mm_aa wrote:

<snip>

> I've enhanced it a bit. It doesn't require to have a toolbar in the
> Shell. As a result, all the initialization can be performed in a View.
> I'm trying to extract all the Tooltip stuff into class. Everything is
> OK until I'm trying to add the support for "dynamic text".

"dynamic text" suggests that you will need to involve the presenters (or
parent presenters) of the tools. The typical Dolphin pattern is for the view
to send a message to its presenter, which by default dispatches the message
back to the view, which then triggers an event off the presenter.

I dont think this is appropriate for Tooltips, because like commands, the
Tool's view may not have an appropriate presenter.

ToolbarButton>>onTipTextRequired routes a command to find the presenter that
takes responsibility for the command, and then makes the assumption (that it
is likely) that this presenter will also supply the Tooltip text. If your
Tools' views are <commandSource>s, you could use the same approach.

While I have not tried this, if your views are not commandSources, I would
still try to implement something similar; maybe routing a "mock" command and
recognizing it in my presenter's #queryCommand:.

> Is there a way to handle a specific View
> message from another class?

Not sure what you mean. Are you adding tools using TTF_IDISHWND or are you
using a uID to keep track of the tools?

Hope this helps. I am planning to do some more work on Tooltips in the next
couple of weeks and try out a few ways of implementing them. If you do any
work on this, I would be interested in hearing how it goes.

Thanks,
Steve

--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html

looking forward to D6 :-) (probably won't buy an AIBO, though ;-).

> Hmm... the fact that IDEA needs to do this seems to me indicative of the
> poor state of Java's reflection interfaces. Such a database is there in
> Smalltalk, of course, but it just happens to be the objects (and classes
and
> methods) themselves.

This is on reason why I was wondering hat the static typers were first - I
believe that the driving force was the requirement for automated
refactoring. Now, that they have the dependency data they can do much more
than they originally thought of.
Regarding reflection, this is not possible as - this is the real point of
it - the instant mentoring works for UNCOMPILABLE code (as you write) as
well as for compiled. There is definitely no secure refactoring possible
with uncompilable code, but most of the mentoring can be done. IDEA managed
to make the best possible assistance with whatever is coded already -
compilable or not.

Reflection in Java is by definition limited, as it allows no access to
private members e.g.. ST is lacking security issues altogether (for good and
for bad). Also you have no correspondence to the position in the sourcecode.
Reflection is a strict runtime feature. What you probably utilize is the
fact that you keep the source-bytecode relationships from the parsing
somewhere.

The other reason of wondering is that ST is typically not filebased but the
source is in a kind of database already. The static typers have to dealy
with all the nasties of silently deleted, moved or modified files etc.

BTW: Have you any plans yet to support some while-you-code assistance in the
future?

Ciao

...Jochen

> I see what you mean by that, and can see how that would be nice,
especially
> in a language which doesn't encourage debugging of partially complete
> programs. In Smalltalk, where I can freely run and debug partially
complete
> programs, I'd often achieve the same effect in Smalltalk by coding in the
> debugger. In other words I'd run the method in the certain knowledge that
> bits are missing, perhaps driving it from a test or by performing some
> command in the application window I've got open, and then going into the
> debugger, and defining the method in there. I like that style because a)
it
> fits the test driven style of first writing the test and then fleshing out
> only what is needed to pass the tests, b) I don't have to write too much
> code before I start testing something, c) the Debugger tends to name the
> arguments correctly in the usual Smalltalk pattern, and  d) I find it
easier
> to write the method in a concrete context.

In general I fully agree whit this beeing advantages of ST. My general
approach is
to build the general framework of classes and methods first (generally
moving bits around a lot)
and begin debugging as soon as I see something is functioning. In this early
stages the possibility
to allow uncompilable methods (which are nicely highlighted in the browser
already) and create methods
like described would be certainly very helpful.

> Certainly you're likely to be able to do a better job on method renames in
> Java because the static type information allows the refactoring engine to
> easily identify which methods actually should be renamed. In practice this
> is less of a problem in classic Smalltalk than it first appears to be
> because Smalltalk programmers soon begin to realise that overuse of common
> selectors such as #add: makes important code reading tools like
> references/definitions (or senders/implementors) significantly less
> effective.  Maybe more could be done with type inferencing, but I would
have
> to defer to John Brant or Don Roberts for an opinion on that one.

True. This reminds me of something I forgot to mention. IDEA by default
shows a list of locations it wants to refactor, sorted by Package/Class. In
this list on can then exclude certain packages/methods from the refactoring.
I think this would be very useful in Dolphin, too.

> Well that's because the syntactic unit the message send, not the message.
It
> would only really make sense to be able to select unary or selectors
anyway,
> because of the way keywords and arguments are interspersed in Smalltalk.
In
> other words I can't really see a way to do that consistently.

Indeed I thought of unary and single keyword messages. see, you are not
using the text but the parser tree.

> I suppose the question is, why do you want to do that? If it's because you
> need to select the selector in order to initiate a refactoring, or perhaps
> kick off a browse references/definitions, then that doesn't really need a
> selection, and for the next version you just need to place the cursor over
> the selector somewhere. I thought about including this change in the last
> patch, but it was a bit to entangled in other stuff. Maybe I'll have a
look
> again for PL4.

Yes, please! :-).


> BTW: You can improve the behaviour of my little method by changing the
> #ifTrue: test at the end to a #whileTrue:. This is needed so that it can
> keep widening out in some circumstances. I've attached a new version
below,
> which will also work for DSE/DVE users, as it includes the #selectedNode
> method that was not in PL2 for those versions.
>
> > Also, by all means, is it possible to enable this in workspaces???
>
> Not at present because that would require some sort of dynamic compilation
> of the content. Since workspaces may often contain multiple snippets of
code
> that are not actually valid when viewed as a whole anyway, I'm not sure
how
> that would work out.
> As an aside I really would discourage you from writing too much code in
workspaces.

Come on - it is a WORK-SPACE ;-). My workspace code is never longer than
fits on one page, otherwise
I refactor to helper classes. Anyway, I do a lot of my daily work there, as
all the launching points are here.

not
> on the
>  menu bar of the receiver's view(s)."
>
>  ^#(#(#widenSourceSelection 'Ctrl+Y'))! !
> !MethodBrowser categoriesFor: #additionalAccelerators!constants!public! !
> !MethodBrowser categoriesFor: #selectedNode!accessing!private! !
> !MethodBrowser categoriesFor: #widenSourceSelection!commands!private! !
>
>

> I just thought I'd mention here, in case it wasn't clear, that Blair is
> referring to the Debug/Implement In command in the Dolphin debugger that
is
> enabled when it is brought up on any message not understood exception.
This
> will automatically implement a method stub in the chosen class with
(often)
> appropriate parameter names. You just have to flesh out the method
contents,
> compile it and then hit F5 to continue. As Blair says, this isn't just for
> fixing the odd method that you've forgotten to implement; you can start
with
> a blank class and use it to flesh out all of the methods one by one as the
> program (or SUnit test) is running. Does IDEA have this ability?

Shure not. As stated, I agree (and it is one reason I  prefer Smalltalk for
my prototyping) that the "online" development is extremly superior to
edit-complie-run cycle development.

However, in design phase I do no edit-complie-run or debugging, but just
toss classes methods and hierarchies around.
Here I would like to have such support also. Anyway, I am shure I can
improve my Smalltalk style a lot and it is well possible that I find such
functionallity less important then.

Ciao

...Jochen

Andy Bower wrote:

> The feedback includes reports on bugs, possible bugs and coding style
> issues.

It is going to be possible to turn this off isn't it ?  I mean *completely*
**OFF**.

;-)  (but only slightly)

    -- chris

Chris,

> > The feedback includes reports on bugs, possible bugs and coding style
> > issues.
>
> It is going to be possible to turn this off isn't it ?  I mean
*completely*
> **OFF**.

You do come across as a bit of a luddite at times :-)

But yes. You can arrange that the mentor only looks at code when you select
the tab in the browser (indeed, this is the default state). You can also
remove the mentor plugin completely if you wish to save screen real-estate.
Personally, I like to leave it on, running in the background, so I
(hopefully) get a little smiley face appearing in the tab a few milliseconds
after any method is compiled. It's all done on a background thread so it
shouldn't affect your workflow at all.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Blair,

> !MethodBrowser methodsFor!
>
> widenSourceSelection
>  | node |
>  node := self selectedNode.
>  node isNil
>   ifTrue:
>    ["Normally we'd just disable the command, but to avoid patch to
> #queryCommand: ..."

This is nice.

The code itself seems to expose a bug in the reformatter code, though.  Doing a
ctrl+shift+s left me with two copies of the comment, one in the original place,
the other after the surrounding block.

Settings:
    RBConfigurableFormatter publishedAspects asSortedCollection
        do: [:each | each display: RBConfigurableFormatter on: Transcript]
        separatedBy: [Transcript cr].

    formatCommentWithStatements=true
    indentsForKeywords=1
    indentString=' '
    lineUpBlockBrackets=false
    maxLineLength=75
    methodSignatureOnMultipleLines=false
    minimumNewLinesBetweenStatements=1
    newLineAfterCascade=true
    newLineBeforeFirstCascade=true
    newLineBeforeFirstKeyword=true
    newLinesAfterMethodComment=2
    newLinesAfterMethodPattern=1
    newLinesAfterTemporaries=2
    numberOfArgumentsForMultiLine=3
    periodsAsTerminators=true
    retainBlankLinesBetweenStatements=true
    stringFollowingReturn=' '
    stringInsideBlocks=''
    stringInsideParentheses=''
    traditionalBinaryPrecedence=an Array
    useTraditionalBinaryPrecedenceForParentheses=true

Oh, BTW, I think that PL2/3 should do:

    RBConfigurableFormatter initialize.

somewhere; the new aspects are nil if you just apply the patches to a clean
image.

    -- chris

Chris,

> > It is going to be possible to turn this off isn't it ?  I mean
> *completely*
> > **OFF**.

> But yes. You can arrange that the mentor only looks at code when you
select
> the tab in the browser (indeed, this is the default state). You can also
> remove the mentor plugin completely if you wish to save screen
real-estate.
> Personally, I like to leave it on, running in the background, so I
> (hopefully) get a little smiley face appearing in the tab a few
milliseconds
> after any method is compiled. It's all done on a background thread so it
> shouldn't affect your workflow at all.

I forgot to mention that the Agent character is entirely optional too (and
off by default).

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]...
> ....
> > > I'm not able to see all local values at the same time. No watches.
> >Certainly these features would be useful, but they are not essential in
the
> >way that they are for file-based static languages.
>
> This is absolutely unrelated to the type of environment IMO. When
debugging
> I always want to see ALL my local and object vars at a glance and not by
> iterating through them. It does not occupy more screen space, either.

You might like to try installing this experimental patch then:

    http://object-arts.com/Lib/Update/Dolphin/5.0/DebuggerValueList.zip

This is a fairly quick enhancement that replaces the variable list with a
multi-column list that also shows the (debug print string of) the values. At
the moment I've left the inspector value pane in as a place to evaluate
expressions, or save down new variable values. The latter could be done by
editing in the list directly too, but I still like to have an immediate
expression evaluation pane over and above the source pane (in which one can
also evaluate expressions in the current context).

Let me know what you think.

Regards

Blair

P.S. For Chris Uppal's benefit, if we adopted this change into a future
patch level or release, we'd still provide the 'Classic view' as an option
:-).

Hi mm_aa,

    I was reading the rich uproar of ideas you have started here.

    I wanted to say to you, to get your own experience clearer, make an
effort to diferenciate the Smalltalk from the Dolphin product. I read pros
and cons that you've posted that mix this two things and that's not helping
anybody.

    I think Andy in 02-19-2003 13:13 put some ideas that could help for
this.

    I'll add to you this:

    I've working with DST for 4 years and we used it to make a Control
System Software that even uses special hardware. The architecture is client
server but it had to be fault tolerant due to transactinal issues, at
software level. This system has sereral applications that interact
reflexively over an ethernet network, uses intesively a stardard DBMS,
serial ports, maps customized drivers of special hard devices.

    Right now I'm trying to make a relexive framework to make distribution
of objects, that is, the object could send messages to each other, even when
they are in diferent hosts, in diferent images (or exe's). I'm having
encouraging results right now.

    All this was made with time, we all matured the tecnology, the designs,
then the product, so don't feel obliged to use smalltalk, it has it's own
tools and it's own way to be 'more productive'.

    If you ask me I'll tell you that I'm more productive with ST, and in the
Dolphin case the MVP, that any other development tool, but until I get this
production speed I have to surpass my own difficulties and nobody was
pressing me to do it, only myself. It's just that I was tired of
conventional procedural tecnologies that every n years are reinvented. I've
found that with smalltalk your designs have the chance, if you can figure
out how to do it, to be more permanent, I mean 'reciclability' if you want.

    I let you only this, not feel obliged or bound, trying to 'be convinced
of' use smalltalk to develop. That's not the way. If you can see that your
own challenges can be better surpassed with smalltalk, so use it, if cannot,
well may be that not the rigth time to start with it for more serious
pruposes. Continue experiencing, and playing with it.

    I see that software is a very unmature branch of the industry 'it's in
it's diapers' and procedural tecnologies, even the object oriented, are
reinventing itselves almost every two or three years independently it's
manufacturer. So every thing I could develop with that environment will
infallibly suffer those consecuences.

    With smalltalk I see that this also could happen but at OS level, inside
an image, the essentials are the same as 30 years, and they are there not
because they miss an update, but because they still are usefull and they
dont loose capabilities, they allways win features with each release.

    So I wanted my projects to inherit this rich experience, so I'm sure I
don't have to reinvet the wheel each time I need a wheel. That's letting me
peaceful because if I where reinventing the wheel I'll have to be alert that
it was 'well invented' (bugs).

    So mm_aa, would be nice to know your name, I want to thank you to make
me remember this and to write it here. It helped to clarify myself once
again why I'm doing what I'm doing, the way I'm doing :) I hope this could
help somebody too.

    best regards

Seb



"mm_aa" <[hidden email]> escribió en el mensaje
news:[hidden email]...
> Andy,
>
> "Andy Bower" <[hidden email]> wrote in message
news:<3e53b46c$[hidden email]>...
> > mm_aa,
> >
> > I too am not convinced that you are not just trolling.
>
> It's quite interesting that almost everyone has ignored my "PROS" part
> ;)
>
>
> > However, my impression from reading your comments is that you are
missing
> > one critical thing when comparing Dolphin with various Java
incarnations.
>
> It's not suprprising - I'm an active Java developer.
>
> > That is that it is Smalltalk.
>
> I'm not trying to touch languages. I was just trying to use a product:
> an IDE + Library + Language implementation.
>
> > 1) It is the "Smalltalk way" to peruse source code to find examples of
it's that
> > dynamic syntax highlighting is not generally considered important.
> > Personally, I've never found a need for it.
>
> That's the reason of IDEA success: none had found a need for
> everything it did. But now, every IDEA users is _so_ accustomed that
> features... And many IDEs are now copying them.
>
> > Small methods also means that the method editor can be relatively
simplistic
> > (as it is in Dolphin). When you are editing huge Java class files you
may
> > need emacs bells and whistles; editing five lines at a time probably
not.
>
> BTW, even with small methods I've found it really frustrating not to
> have "Undo" working through method code saves.
>
> And what about completion for all that wrappers for external methods?
> (whith 5/7 parameters)
>
> > 3) It is the "Smalltalk way" to work inside a "sea of live objects" (the
> > image) that contains the development tools along with the source.
Providing
> > you learn to take care this is virtually never a problem. Yes, you can
break
> > something by putting breakpoints in key bits of code but just restart
and
> > remember not to do it again. It has been over a year since I
accidentally
> > broke an image like this.
>
> I'm breaking it 3 times a day ;)
>
>
> > 4) It is the "Smalltalk way" to develop inside the debugger while the
> > application is running. I've heard that you can (at last) recompile
methods
> > inside some Javas' debuggers, but can you define new methods (as a
result of
> > a #doesNotUnderstand: fault) create new classes and refactor the entire
> > system?
>
> Nope. But due to static typing I rarely need that.
>
> > I haven't seen it but I suspect not. Certainly in all the Java IDEs
> > I've seen (I admit to not having used IDEA - I note it is 150% the price
of better
> > and productive than other languages like Java.
>
> Currently, I'm being much more productive with Java ;)

> Let me know what you think.

Just brilliant! Exactly how I dreamt of it - especially that you kept the
workspace for input.
These "quick" patches doing so nice improvements really make me wonder what
you will come up with in D6 :-)

Ciao

...Jochen

Interenting experience you have

    chau

Seb


"Jochen Riekhof" <[hidden email]> escribió en el mensaje
news:[hidden email]...
> Hi Seb...
>
> > please could you explain more about 'Performance is about factor twenty
> lower than Java HotSpot'
>
> My current main use of Dolphin is to prototype all sorts of algorithms
e.g.
> image processing and numerics. The image-based and interpreted apoproach
of
> Smalltalk is ideal for this. My experience so far is that the average
speed
> of execution of the algorithms is about twenty times faster when ported to
> java (No, I do NOT optimize the Java code and write dumb ST code, but
rather is
> quickly passed down to Windows, so the VM is released of this burden. The
> Windows code is native code that is quick but not very clean from the
object
> oriented viewpoint to say the least. Dolphin does a nice job in hiding the
> latter fact from you, the GUI developer, while maintaining the speed of
the
> native GUI framework. Also, a deployed Dolphin app is very small and needs
> no further installations, Java OTOH is quite a fat lady. For this reason
it
> is the main issue in a court fighting between SUN and Microsoft to forde
MS
> to deliver the Java runtime with the OS. You donÄt have to care if you use
> Dolphin :-).
>
> Due to the Swing slowness, e.g. IBM proposes its native SWT widget library
> for some time now, most prominent implementor of this library is IBM's
> Eclipse IDE.
>
>  Sidenote: Java is currently fighting not with speed problems, the VM is
> actually very fast, but with slowness due to memory management with
millions
> of Objects on the heap. The VM is very memory intensive and we are dealing
a
> lot with optimizing garbage collection on bigger projects. We had on 2GHz
> systems GC times sometimes exceeding 2 seconds! Garbage collection is
great,
> but the bookkeeping work it keeps from the programmer has to be done
> elsewhere, apparently.
>
> Ciao
>
> ...Jochen
>
>

Jochen Riekhof wrote:
Try VisualWorks Smalltalk or VisualAge Smalltalk.  These are dynmically
compiled and hence have much higher Smalltalk compute performance than
Dolphin.  I think you'd find that for symbolic computation VisualWorks
was equivalent to Java in speed...





--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

Steve,

> Not sure what you mean. Are you adding tools using TTF_IDISHWND or are you
> using a uID to keep track of the tools?

I just want to move the tooltip support to move in _whole_ to the
dedicated class (honestly saying, I don't like the smalltalk way to
have miriads of methods in one class which do everything). That's why
I need to dispatch TTN_NEEDTEXTA not inside the view, but inside the
Tooltip class, which will route the necessary commands to the
presenter.


> couple of weeks and try out a few ways of implementing them. If you do any
> work on this, I would be interested in hearing how it goes.

Here's the code I have. (Please keep in mind that it's the code I
write in the very beginning of smalltalk usage). I had also variant,
which uses tracking tooltips, but I removed the tracking tooltips
support, since didn't need them. However it's really simple to add it
here.


Object subclass: #Tooltip
        instanceVariableNames: 'handle view interactor mouseX mouseY
oldNmNotify text'
        classVariableNames: 'NmMap'
        poolDictionaries: 'CommCtrlConstants Win32Constants'
        classInstanceVariableNames: ''!


createWindow
        ^UserLibrary default
                createWindowEx: WS_EX_TOPMOST
                lpClassName: 'tooltips_class32'
                lpWindowName: nil
                dwStyle: WS_POPUP | TTS_NOPREFIX | TTS_ALWAYSTIP
                x: CW_USEDEFAULT
                y: CW_USEDEFAULT
                nWidth: CW_USEDEFAULT
                nHeight: CW_USEDEFAULT
                hWndParent: view handle
                hMenu: nil
                hInstance: VMLibrary default applicationHandle
                lpParam: nil!

install: aView
        | ti |
        self view: aView.
        self substituteInteractor.
        handle := self createWindow.
        UserLibrary default
                setWindowPos: handle
                hWndInsertAfter: HWND_TOPMOST
                x: 0
                y: 0
                cx: 0
                cy: 0
                uFlags: SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE.
        ti := TOOLINFO new.
        ti
                uFlags: TTF_SUBCLASS | TTF_IDISHWND;
                hwnd: aView handle;
                uId: aView handle.
        self text isNil ifTrue: [ti textCallback] ifFalse: [ti text: self
text].
        UserLibrary default
                sendMessage: handle
                msg: TTM_ADDTOOL
                wParam: 0
                lParam: ti yourAddress!

onGetCursor: aSymbol
        ^interactor onGetCursor: aSymbol.!

onLeftButtonDoubleClicked: aMouseEvent
        ^interactor onLeftButtonDoubleClicked: aMouseEvent!

onLeftButtonPressed: aMouseEvent
        ^interactor onLeftButtonPressed: aMouseEvent.!

onLeftButtonReleased: aMouseEvent
        ^interactor onLeftButtonReleased: aMouseEvent.!

onMiddleButtonDoubleClicked: aMouseEvent
        ^interactor onMiddleButtonDoubleClicked: aMouseEvent
!

onMiddleButtonPressed: aMouseEvent
        ^interactor onMiddleButtonPressed: aMouseEvent
!

onMiddleButtonReleased: aMouseEvent
        ^interactor onMiddleButtonReleased: aMouseEvent !

onMouseMoved: aMouseEvent
        aMouseEvent x ~= mouseX & (aMouseEvent y ~= mouseY)
                ifTrue:
                        [mouseX := aMouseEvent x.
                        mouseY := aMouseEvent y.
                        UserLibrary default
                                sendMessage: handle
                                msg: 1052
                                wParam: 0
                                lParam: 0
                        .
        ^interactor onMouseMoved: aMouseEvent!

onRightButtonDoubleClicked: aMouseEvent
        ^interactor onRightButtonDoubleClicked: aMouseEvent
!

onRightButtonPressed: aMouseEvent
        ^interactor onRightButtonPressed: aMouseEvent
!

onRightButtonReleased: aMouseEvent
        ^interactor onRightButtonReleased: aMouseEvent
.!

substituteInteractor
        interactor := view interactor.
        view interactor: self!

text
        ^text!

text: anObject
        text := anObject!

view
        ^view!

view: anObject
        view := anObject! !