freeride-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [FR-devel] FileOpenDialog/FileSaveDialog, etc


From: Curt Hibbs
Subject: RE: [FR-devel] FileOpenDialog/FileSaveDialog, etc
Date: Tue, 1 Oct 2002 05:53:57 -0700

Laurent Julliard wrote:
>
> Rich Kilmer wrote:
> > Question on implementation:
> >
> > Currently, to use these services one does something like:
> >
> > @plugin['/system/ui/services/FileSaveDialog'].call(@@current_dir,
> > "untitled#{$1}.rb")
> > answer = @plugin['/system/ui/services/FileSaveDialog/answer'].data
> > filename = @plugin['/system/ui/services/FileSaveDialog/filename'].data
> >
> > I was wondering about the logic of setting the results to be "global"
> > slot values (/answer and /filename)...why not just do:
> >
> > answer, filename =
> >   @plugin['/system/ui/services/FileSaveDialog'].call(@@current_dir,
> > "untitled#{$1}.rb")
> >
> > I don't see the value in the indirection.
> >
> > The point is, for consistency, we either need all proc slots to return
> > values, or set them in slots.
> >
> > I for one would rather have the direct return, unless there is an
> > architecturally useful reason otherwise.
> >
> > Thanks,
> >
>
> I agree with you. In most cases services like these should return the
> value directly. The only case I can think of where there is an
> interest to store the return value in slots is for debugging purposes
> but it could as well be printed in the log file.
>
> Another point in favor of the change is that FR is going to be a
> thread intensive application as I see it and having sveral threads
> using the services at the same time and using global data slots to
> store the results could lead to interesting data overwriting.
>
> So my take a this is go and make the change.

I'll take the credit for the current (poor) design. I also agree completely
with this change -- go for it!

Curt





reply via email to

[Prev in Thread] Current Thread [Next in Thread]