Common uses for loose methods?

What are some common uses for loose methods?

Griff,

always if you need a method in a "base" class, or in someone else's
packages, you create a method in that class (class or instance side),
but "physically" they are stored in your own package.

Another mental model about them: They are the -for you necessary-
extensions or changes in classes in other packages. It is better you
never change physically the for ex. the Dolphin Base package, because
the next release, or patch level can simply overwrite (i.e: delete)
your changes. But you can load your package then in the new release or
version and voilá: your extensions and changes are there again. (or as
in the example below you can see they are not necessary any more).

Others may have much better examples, I have one from the D5. (In MSDN
you can search for Chris Uppal's answer on "Graphics Regions, how to
use").

In Dolphin 5 I needed an elliptic graphic region, Chris wrote:

"you need to create an instance of Region that corresponds to an
ellipse.
The second problem is that Dolphin doesn't come as standard with a full
range
of Region-creation methods, so you will need to add one (and possibly
more
later).

Start by looking at class Region (on the class-side).  You'll see that
it has a
#rectangle: method which creates a rectangular Region using the GDI
function
CreateRectRgnIndirect().  As it happens, GDI contains a similar
function,
CreateEllipticRgnIndirect(), which takes exactly the same parameters
but
creates an ellipse, so it should be easy to add a call to that.  Create
a new
instance-creation method on Region

===================
    ellipse: aRectangle
        "Answer an elliptical region defined by aRectangle"

        ^self fromOwnedHandle:
            (GDILibrary default createEllipticRgnIndirect: aRectangle
asParameter)
===================

which is just the code for #rectangle with small mods to call a
different
function.  Then you'll have to ensure that the GDILibrary class does
actually
define the method #createEllipticRgnIndirect:.  In this case it turns
out not
to (sometimes you'll find that the lowest-level wrapper functons do
exist even
if they are not used by higher-level classes elsewhere in the image).
So you
need to add the following method to the instance-side of GDILibrary.

===================
    createEllipticRgnIndirect: aRECT
        "The CreateRectRgnIndirect function creates an elliptcal
region.

            HRGN CreateEllipticRgnIndirect(
            CONST RECT *lprc  // pointer to the rectangle
            );"

        <stdcall: handle CreateEllipticRgnIndirect RECT* >
        ^self invalidCall
===================

which is, again, just the same code as #createRectRgnIndirect: with
small
modifications.

With those two methods added, you should be able to say:

    myellipse:= Region ellipse: (Rectangle origin: 100@100 extent:
50@30).
"

At that time both Region class>>ellipse: (in Dolphin MVP Base) and the
GDILibrary>>createEllipticRgnIndirect: also in the Dolphin MVP Base)
were "loose" methods, i.e: they belonged to classes in other packages,
but physicaly I stored them in my own JkaGraphicsExtensions package.

Chris' proposal was incorporated in D6, you can see the result in the
classes above in D6. Also it means I do not need them as loose methods
any more in my graphics extensions package.

Regards,
Janos

I see, interesting.

of course I meant DSDN at the search above... it is to hot now in
Europe.

I didn't catch that. I was impressed that someone got published in MSDN
using Dolphin!

Janos wrote:
> of course I meant DSDN at the search above... it is to hot now in
> Europe.

Griff wrote:

> What are some common uses for loose methods?

I see three categories of uses -- in order of increasing importance:

Fixing problems with existing code.

Extending existing code to provide new features which the originator had either
not thought of, or not yet got around to.  (Incidentally this is much more
important than it looks at first sight, because it frees the original designer
from the burden of having to get everything right first time -- with the
consequential increased  fear and risk of paralysis or over-engineering).  E.g
in the example Janos quoted, Object Arts didn't have to waste time writing (and
testing) the methods for creating elliptical Regions -- which maybe nobody
would ever need -- since they knew that if someone /did/ need them, they could
add them themselves without being forced to write awkward code.

Allowing you to package behaviour (what characterises a particular object and
its role(s) in a system) separately from functionality (software layering, and
grouping code by domain).  E.g one package might define (the old OO favourite
;-) a group of Shape classes which knew how to do geometry such as computing
their intersections and so on.  A separate package might be about displaying
those shapes in a window and might add extra behaviour to the objects which
allowed them to take charge of their own visual representation.

    -- chris