Robert D. schrieb:
Sounds interesting.
I don’t know, because it is a special situatuation, and it is very
experimental.
During usage i build something like a hybride human-software process. At
start
some helper libraries are required in “irb”, and then I worked with
several data
in different buffers, writing helpful code for analysis and changes and
throw
the code away after the work is done (usually there is no future use for
the
code). If one wants to use this in a “real program” s/he must find out
how to
generate (=create) useful Ruby code based on some events - I mean code,
that is
not predictable when the program starts.
Robert D. schrieb:
Could you give an example?
This is difficult, because there is no fixed code, but I can decribe a
typical
process.
Someone comes to me with a CD (or ZIP file via mail) with several
textual files,
and says “…something is wrong there…”, or “…can you help me by
producing a
short overview…”. Especially in the first situation I have nearly no
addition
information. So I load one File into a line oriented buffer structure
(based on
an Array of Strings) an start analysing the data by using helper methods
and
regular expressions.
Sometimes (=often) the files have explicit relationships via textual
remarks.
This is one case, where the usage of singleton methods for lines
(=String
objects in an Array) comes up, because it is simple and easy to use. It
follows
usually the same pattern:
buffer.each do |line|
if (md = line.match(/a pattern that is of some interest/)
# define a special method for the line
end
end
The definition will take place on the assumption, that the method may be
useful
later on, which is not clear in the moment. It is possible, that the
method
opens a new buffer, loads another file and does some action on it.
This can happen several times. Later it is possible that I want, that a
buffer
applyies such a method for each line the method is defined. I can use
the
following short pattern for this:
buffer.each{|line|line.my_method if line.respond_to?(:my_method)}
Remarks:
-
Performance isn’t a interesting thing in this situation. When I think
about
an output and plan what to do next, I am the bottle-neck in the system.
-
This kind of using singleton methods is attractive, because it isn’t
complicated and simple to use (=not much to write), what is very
interesting in
an interactive session.
-
Readability of the code isn’t relevant, because it will be thrown
away after
usage. This can be done, because the problems differ very much. Reusable
things
will be build in the libraries, that I require in the very beginning.
-
Readability isn’t a big problem, because I wrote some large TECO
programs
long time ago…
I Think this is a very special usage of Ruby.
Wolfgang Nádasi-Donner