Ted Dennison <dennison@telepath.com> a �crit dans le message :
7qpd5b$1gg$1@nnrp1.deja.com...
> I'll agree that Francois might have gone a bit overboard. But I must
> confess I'm one who never has understood the "power" of separates
> either. As near as I can tell, its only power is the ability to split up
> cumbersome files into smaller files without having to go through the
> pain of properly reencapsulating functionality into new packages. Does
> it have other "powers" that I'm missing?
>
Pluggable modules. You can write a big library that needs some
functionnality to be adjusted (depending on the OS, or whatever). If the
functionnality is provided as a "separate", you can change it without even
looking into the (big, complicated) library. On some systems, you would'nt
even need to provide the source of the library, so a customer could provide
it's own version, without being able to see your (proprietary) big library.

Why not use a (child) package for that ? If the separate module needs to
access global data from the package body. Note that if you are clever
enough, you won't expose what the separate procedure needs not to see:

package body pack is
    -- data visible to the separate proc goes here
   procedure to_be_adjusted is separate;

   -- data not visible to the separate proc goes here
  ...
end pack;

If you use a child package, then the "data visible" must be put in the
private part of the parent, which may have other drawbacks.

In short: there is certainly no definitive "best solution". The best
recommendation is: "know the tools that are available, know their drawbacks
and benefits, and choose the most appropriate for the task at hand on a case
by case basis".

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog