Thanks for your input, Moritz. The problem I see with passing this
semi-global information as a parameter is that in theory every time I
create a new object from one of my own classes I need to pass this data as
parameter during instantiation (this, to me, is the most logical place to
do it). If the created object doesn't need the data today, then there is no
need for this extra parameter, but it might need it tomorrow, which means
that code both in the calling class(es) and the called class needs to be
changed. If this data is always available to every class at any time, the
requirement to make global changes is minimised. Well, this is my way of
looking at it.
Staffan
On Wed, May 7, 2014 at 9:31 AM, Moritz Hoffmann <antig...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Staffan,
>
> you're describing the issue very well: the .LOCAL object is
> process-local (.ENVIRONMENT used to be system wide on OS/2) so in fact
> everything in there is shared between all objects and threads. The
> solution you're suggesting is the right one: put the relevant data
> into objects and pass them as parameters. This is much cleaner object
> oriented design than relying on the implicitly shared .LOCAL storage.
> It might appear cumbersome at first to explicitly model everything as
> classes, but in the end it might lead to a much simpler and easier to
> maintain design.
>
> HTH, Moritz
>
> On 05/06/2014 06:29 PM, Staffan Tylen wrote:
> > I'm looking for a better solution that what I currently have put in
> > place. Consider class A, it sets up various information in the
> > .LOCAL directory. It then initiates child task B1 running code
> > that is defined in class B. Then A starts child task B2 also
> > running class B. Both B1 and B2 need to use their own set of local
> > data. Methods in B make use of lots of other classes and many of
> > the methods in them need access not only to the data in the .LOCAL
> > directory but also to the unique task-related data. So how can I,
> > in an elegant way, make this data directly available to all these
> > methods? I have no other solution than passing an object with the
> > task-related data to the methods that need it as a parameter, but
> > there MUST be a better way of doing it. I've been thinking that
> > maybe INHERIT could be used somehow, but I haven't been able to
> > figure out how. I've also looked at finding some piece of
> > information within the ooRexx environment, always accessible, that
> > uniquely identifies each task B1 and B2 and that I could use as key
> > for a .LOCAL directory, but I can't find any such information. So
> > does anybody have a dream-solution to this?
> >
> > Thanks, Staffan
> - --
> Moritz Hoffmann
> http://antiguru.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iF4EAREIAAYFAlNp4W4ACgkQ264ap80Va8c25gD+MYUTsv/dHU3GJeE5//DgTr0Z
> +y8uRr2dysgMQveXZFsA/R0iWMfJbf0K7aFpDu0rlyQLG1CGPXKMptPNia3/hgO3
> =2X7W
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Oorexx-users mailing list
> Oorexx-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-users
>
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
