Easy Way to copy a class?

Is there an easy way to copy a class in Dolphin? I know older smalltalks
left you on your own, but dolphin seems to have a fuller set of useful
functionality.

I have an abstract class with subclasses that override methods to implement
bits of functionality. I want to copy one of the subclasses to use it as a
template for an alternate implementation - do I really have to create the
subclass and then copy each of the methods over?

Along the same lines, when using the refactorng tools -and wanting to push
up a method from one of these subclasses to the superclass - it complained
that my superclass "wasn't an abstract class". How do I indicate that it is?
However I do want to inherit some useful class method constructors instead
of duplicating them in the subclasses.

Tim

TimM wrote:
> Is there an easy way to copy a class in Dolphin?

Yes, or fairly easy anyway.

In the top-middle pane of the CHB, all the categories, variables, and
protocols, can be used as drag-and-drop sources.  What gets dragged is the set
of methods that they "select", so to copy a group of methods to another class,
just drag-copy the corresponding group.  For instance, to copy all the methods,
select the 'All' root of the Categories tree and drag that to another class.

    -- chris

There is no direct way to copy a class. But you can make use of the
fact that dragging and dropping a method category or method to another
class does a copy. Create the new subclass as per normal. Dragging the
"All" category to the new class will copy all the methods over. You
need to repeat this for the class side.

Not sure about the Push Up problem. An abstract class is probably one
with a method that sends #subclassResponsibility.

--
Hwee Boon

I suppose thats not too bad. Thanks for the tip. If I get time, I guess I
can write a simple copier and add it to the relevent menu... but then
there's never enough time... ;-)

Tim

"Chris Uppal" <[hidden email]> wrote in message
news:42fe0b53$0$38037$[hidden email]...

Tim,

> Is there an easy way to copy a class in Dolphin? I know older smalltalks
> left you on your own, but dolphin seems to have a fuller set of useful
> functionality.
>
> I have an abstract class with subclasses that override methods to implement
> bits of functionality. I want to copy one of the subclasses to use it as a
> template for an alternate implementation - do I really have to create the
> subclass and then copy each of the methods over?

Usually when I do the (described elsewhere) message dragging trick to
copy a class, it is to avoid having the RB reformat code.  If your goal
is to ensure that your classes understand a common protocol, consider
the protocol browser.  It does a very nice job of stubbing methods that
should be present in classes.  Create a protocol, add methods to it,
then list classes as conforming to said protocol.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

TimM,

> I suppose thats not too bad. Thanks for the tip. If I get time, I
> guess I can write a simple copier and add it to the relevent menu...
> but then there's never enough time... ;-)

Well that's one reason the menu command isn't there already. The other
is to avoid bloat. In my experience copy class is a pretty rare
operation. As far as I can remember, the number of times I have ever
wanted to copy a Smalltalk class must be under 10, probably more like
five or six. And that's in 12 years or so of Smalltalking!

In my experience, I have only ever wanted to do it to "make a temporary
backup" of a working class while I experiment with some changes but, as
you know, there are already several other ways of doing that: image
save, package save and SCCS check-in. I don't *think* I've ever wanted
to copy a class to make another permanent class that is similar but not
identical in behaviour.

But maybe I'm just odd.

Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> In my experience, I have only ever wanted to do it to "make a temporary
> backup" of a working class while I experiment with some changes but, as
> you know, there are already several other ways of doing that: image
> save, package save and SCCS check-in. I don't *think* I've ever wanted
> to copy a class to make another permanent class that is similar but not
> identical in behaviour.
>
> But maybe I'm just odd.

You mean any more so than the rest of us? :)  I agree that copying a
class is not all that common; methods and pieces thereof are a different
matter, but there are ways to handle them.  I will sometimes create a
class and drag all methods to it (copy a class) to avoid having the RB
format my code as part of renaming.  Otherwise, I suspect I have avoided
this particular form of "reuse".

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Guys - I take on board your comments. As many of you are experts in
Smalltalk - I can see how you might never need to copy a class and might
automatically figure out a protocol "upfront", create it and then make a new
class conform to it.

However it is also quite conceivable to approach the problem in a more
mechanical way - copy the class, edit the methods and slowly work out the
duplication and then use a refactoring tool to eliminate it. Eventually you
might work out a protocol and can then introduce it in the protocol browser.
This seems like a more organic approach that is equally compatible to
Smalltalk.

Furthermore - with packages going on in Dolphin, the create a class and then
drag methods accross is prone to ending up with loose methods in your class
belonging to another package which further complicates things from a new
users perspective.

Given the rich suite of tools that Dolphin provides, I think copy class is
missing from a "new users" point of view. This is particularly true given
that Smalltalk doesn't deal with "files" so you can't just copy a file to
duplicate it. As for "image bloat" - the refactoring tools already add the
other useful "first timer" otpions to add instance variables etc. so it just
rounds out the offering.

However, I can add the relevent option myself and produce it as a "goodie"
so its not a big deal. I do think its worth keeping an open mind on these
things though, just becuase its always been done a particular way - doesn't
mean that it should always be done that way. I quite like how Dolphin breaks
many of the pre-conceived notions of old smalltalk (a text editor component
not written in Smalltalk - sacrilige... but it works nice though... ;-)

Tim


"Bill Schwab" <[hidden email]> wrote in message
news:hDqLe.5068$[hidden email]...

Tim,

> Guys - I take on board your comments. As many of you are experts in
> Smalltalk - I can see how you might never need to copy a class and might
> automatically figure out a protocol "upfront", create it and then make a new
> class conform to it.

Try the protocol browser, even on a small throw-away project.  It is not
as limiting as you might think.  I will admit that it would drive you
nuts to tweak a protocol at ever step of development, but that really
should not be necessary.



> Given the rich suite of tools that Dolphin provides, I think copy class is
> missing from a "new users" point of view. This is particularly true given
> that Smalltalk doesn't deal with "files" so you can't just copy a file to
> duplicate it. As for "image bloat" - the refactoring tools already add the
> other useful "first timer" otpions to add instance variables etc. so it just
> rounds out the offering.

Fair enough, but from a mentoring perspective, we want newbies to add
instance variables, we don't want them to copy classes as a routine
task.  Adding something to the IDE suggests it is correct behavior.
Makes one wonder why there are Java IDEs :)


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Andy, Tim,

> Well that's one reason the menu command isn't there already. The other
> is to avoid bloat. In my experience copy class is a pretty rare
> operation. As far as I can remember, the number of times I have ever
> wanted to copy a Smalltalk class must be under 10, probably more like
> five or six. And that's in 12 years or so of Smalltalking!

FWIW, I find that I copy classes rather often -- not as often as once a week,
but certainly more than once a month.

Various reasons: I may want to use a duplicate of an existing class as a
starting point from which I will create a mutated version.  I may want to have
similar functionality in two classes that (for any of several reasons)
shouldn't be related by inheritance.  I may want to explore a different
implementation of an existing class's behaviour.  I may just be lazy...

The duplication of functionality via code copying (which is not always
inapropropriate) is a response, in part, to the absence of mixins in Smalltalk
(which I've already mentioned that I find very inconvenient).  Two problems in
the Dolphin GUI encourage whole-sale duplication of classes as a starting
point, rather than more selective copying later in the design/coding process.
Both have been mentioned before.  One is the "did not compile" popup, I usually
know that the code won't compile, but the popup appears for every method
copied, so it's easier just to copy everything at the start and get it over
with.  The second is that copying a group of methods, when once of them would
overwrite an existing method (when I don't want that to happen) doesn't work --
if I tell Dolphin that I don't want it to overwrite that method then it
terminates the copy loop, but I don't know which methods have been copied and
which have not.

    -- chris

TimM wrote:

> Given the rich suite of tools that Dolphin provides, I think copy class is
> missing from a "new users" point of view.

It may be.  This is certainly something of a FAQ.

But I don't think that I'd support adding it as a top-level operation.  The
reason is that there is already a more general operation (copying groups of
methods) which includes it as a sub-case, so: (a) I don't see that it would add
enough value to justify an extra operation added to the GUI, and (b) I think
that having it would discourage beginners from discovering the more general
operation.

BTW, in the Dolphin GUI just about /everything/ is drag-and-droppable (the only
exception I can think of off-hand is the "System folder" -- where dragging the
icons wouldn't mean much).  The drag operation is always interpreted as a
sensible and useful operation, though -- of course -- it may not be the
operation that you hoped it would perform.  (E.g. dragging an instvar doesn't
copy/move the instvar but the methods that refer to it.)

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:43004b1c$1$38041$[hidden email]...
Both of which problems will be fixed in the Dolphin 6 release. I think the
first of these was actually fixed in beta 1. You get a single message box,
even if there are multiple failures.

BTW: I am persuaded there should be a 'Copy Class' refactoring. Whether it
gets into D6 or not will depend on the availability of time (there is no
shortage of things to do already). If someone wants to contribute a
refactoring class, then I promise it will get integrated.

Regards

Blair

Blair,

> Both of which problems will be fixed in the Dolphin 6 release. I think the
> first of these was actually fixed in beta 1. You get a single message box,
> even if there are multiple failures.

The problem is not that there is one popup per "error" (that's fixed in D5, in
fact) but that there is a popup at all.  I /know/ it's going to fail, and I
know exactly /why/ it's going to fail, it's just irritating to have to OK a
popup on top of getting entries in the transcript and red marker icons in the
method list.

I know I can fettle it myself, and I'm not sure why I haven't got around to
doing so so far, but I'm not the only person it bothers.

    -- chris

Chris, Blair,

> The problem is not that there is one popup per "error" (that's fixed in D5, in
> fact) but that there is a popup at all.  I /know/ it's going to fail, and I
> know exactly /why/ it's going to fail, it's just irritating to have to OK a
> popup on top of getting entries in the transcript and red marker icons in the
> method list.
>
> I know I can fettle it myself, and I'm not sure why I haven't got around to
> doing so so far, but I'm not the only person it bothers.

I have long thought that when dragging a method to a new class, the
popup that gets between me and fixing a missing/clashing iv problem is
pointless.  It would be better to simply transfer focus to the drop
target - the red source color would be a good clue that something is out
of whack.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Chris Uppal" <[hidden email]> wrote in message
news:43019292$0$38038$[hidden email]...
Well actually you said:

    "One [problem in the Dolphin UI] is the "did not compile" popup, I
usually know that the code won't compile, but the popup appears for every
method copied, so it's easier just to copy everything at the start and get
it over with."

So in fact that isn't the case in D5 either?.

>
> I know I can fettle it myself, and I'm not sure why I haven't got around
> to
> doing so so far, but I'm not the only person it bothers.
>

I hear you - this will be a suppressable message box in the release.

Regards

Blair

Blair McGlashan wrote:

> Well actually you said:
>
>     "One [problem in the Dolphin UI] is the "did not compile" popup, I
> usually know that the code won't compile, but the popup appears for every
> method copied, so it's easier just to copy everything at the start and get
> it over with."
>
> So in fact that isn't the case in D5 either?.

It is when you copy the methods one-by-one (or in small batches) which is the
case I was contrasting against a single copy-the-lot operation.

    -- chris