Page 1 of 1

Suggestions: Temporary files + Object orientation

Posted: Fri Aug 14, 2009 6:46 am
by ChrisFM
I've bumped into two problem recently, where I'd like to do the following:

1) Create a program "on the fly", run it, and then delete the program (because it is only a "temporary" file);
2) Refer to a list of objects on a page, but I don't know their names in advance.

For #1, can I suggest that you add a "cleanup" flag to any "save" command -- that is, Eviews would delete the file after you exit. I can understand why you would want to limit access to the file system, but it would be nice to delete the file. Alternatively, expose the system %temp% environment variable, allowing you to save to the temporary directory. (See below)

For #2, objects in Eviews should be a bit more objected-oriented, with a "standard" set of properties/methods, including:

Code: Select all

[u]Properties[/u] .name Item name (*not* the label, but the actual variable name) .children A collection of all the children .children.count Number of children in the collection .type Item type (workfile, page, text, series, frml, sspace, etc...) .label The label (for some items, such as pages, .label = .name) .dimension A vector of the dimensions (a series: [@obs,1], a group: [@obs,N], a table/matrix: [r,c], sspace: [# eq, #variables], etc.. [u]Methods[/u] .copy .rename .delete .move .save Saves to disk in: txt, xls, or other formats, including with an option (temp) to save to temporary directory[/b] .print .import Imports data (including through fetch from DB) into the current object Thus, a page.import would import series, a series.import would import the data into the current series). Some possible cool options: smpl=s Import data into the specified sample tmp Import data from the temporary directory (so any file name would not need a directory path)

Re: Suggestions: Temporary files + Object orientation

Posted: Fri Aug 14, 2009 7:34 am
by EViews Gareth
I don't understand #1, but #2 has already been implemented for EViews 7.

Re: Suggestions: Temporary files + Object orientation

Posted: Fri Aug 14, 2009 8:28 am
by ChrisFM
Great to hear on #2! Do you have a list of "standard" properties/methods?

On #1 -- as far as I can tell in Eviews, you do not have a lot of interaction with the filesystem. You can save/open/import data, but that is it. You cannot delete or rename files (or execute commands through a shell).

The reason you might want #1, if you want to create a program from within a program. (This is actually a very useful feature -- since then you could do things like have dynamic includes -- getting around any limits on the use of {%s} string replacement variables.)

However, if you do create a dynamic program (it is possible right now to do so!), then you cannot delete the temporary .prg file. If you run a lot of these programs, there are "stray" .prg files left on the disk. OK -- I know a text file doesn't take a lot of disk space, but stray .prg files grind on my nerves and set me off on a major OCD anxiety attack... :shock:

More clear?

Re: Suggestions: Temporary files + Object orientation

Posted: Fri Aug 14, 2009 8:45 am
by EViews Gareth
When you say you can't "execute commands through a shell", have you tried the shell command?

Re: Suggestions: Temporary files + Object orientation

Posted: Fri Aug 14, 2009 9:19 am
by startz
Perhaps "shell" could be added to the list of items indexed in the help file. (Mind you, it can be found by search.)

Re: Suggestions: Temporary files + Object orientation

Posted: Fri Aug 14, 2009 10:27 am
by ChrisFM
Shell and spawn would do it! Thanks -- and including it in the index + list of program commands would be most helpful.

Since you've exposed the OS via Eviews, can I suggest that you go the next step and create a "OS" object, where you could access folders, files, and environment variables? (Shell is an easy way to do so, but exposing an object would be more consistent).

Re: Suggestions: Temporary files + Object orientation

Posted: Fri Aug 14, 2009 10:48 am
by EViews Gareth
You have to remember that EViews objects are workfile based, not program based. Having an "OS" object inside a workfile doesn't seem to make much sense.