Guten abend Rony,
> - "Partial arguments": this looks very interesting. However, I have
> been a little bit surprised that the creation of the final argument array
> does not append the new arguments to the partial ones and also leaves out
> array entries that are empty. Why is this? It may be the case that for some
> analysis it becomes important to be able to learn whether an argument was
> omitted or not.
>
> Since ooRexx lets omit arguments, I thought it was interesting to keep
this feature for partial arguments.
An example with oodialog. I give the signature of the method, and then I
define a closure for this method, with partial arguments. You will see that
createTahoma keeps omitted arguments. Some of these omitted arguments are
provided by createCenteredTahoma (chained partials).
The first argument of the closures is an instance of .UserDialog, because
the closures are built from a message (so the 1st arg becomes the receiver).
PS : I don't claim this example is a good example with oodialog. I needed
methods with many arguments, to illustrate ~partial with omitted arguments.
And oodialog fits this need. This example also demonstrates that closures
are functional, not object-oriented.
-- .UserDialog~create(x, y, cx, cy, title, style, dlgClass, fontName,
fontSize, expected)
-- createTahoma(dialog, x, y, cx, cy, title, style, fontSize, expected)
createTahoma = "create"~partial(,,,,,,,"","Tahoma")
-- for illustration of chained partials (could use ~createCenter directly)
-- createCenteredTahoma(dialog, cx, cy, title, fontSize, expected)
createCenteredTahoma = createTahoma~partial(,0,0,,,,"center")
-- .UserDialog~createStaticText(id, x, y, cx, cy, style, text)
-- createStaticText(dialog, cx, cy, text)
createStaticText = "createStaticText"~partial(,-1,1,1,,,"SUNKEN")
dialog = .UserDialog~new
createCenteredTahoma~(dialog, 100, 10, "hello", 30)
createStaticText~(dialog,,, "this is a static text (close me)")
dialog~execute("showtop")
::requires "oodialog.cls"
::requires "extension/extensions.cls"
> - "Higher-order functions": are the following basic definitions
> correct?
> - "reduce": iterates over the items of a collection and supplies
> them one by one as an argument to the block processing/accumulating
> them in
> one way or the other.
> - "each": iterates over the items of a collection and returns an
> array in which each visited item was processed according to the
> RexxBlock,
> - "map": iterates over the items of a collection and returns the
> collection in which each visitied item was processed according to the
> RexxBlock,
> - "reduceW" is "reduceWords", "reduceC" is "reduceChar", "mapW" is
> "mapWords", "mapC" is "mapChars", "eachW" is "eachWords", "eachC" is
> "eachChars": they are available for .String and .MutableBuffer and
> there as
> a convenience (assuming that one could always create an array of words
> or
> chars from a string and then use "reduce", "map" and "each" on them)?
>
>
yes, all this is correct
> - "Higher-order functions":
> - What are "mapR" and "eachI" for?
>
>
"R" stands for "Replace" :
~map returns a copy of the collection.
~mapR modifies the collection in-place.
"I" stands for "Indexed"
~each returns an array of results
~eachI returns an array of results and indexes. In the dropbox delivery,
it's an array of two arrays. I'm reworking that in my sandbox : now it's an
array of pairs (result, index). This is because I'm implementing a specific
version of ~each for the coactivities. A lazy ~each must yield one result
at a time, so when indexed, must be a pair (result, index).
>
> - What are "mapCR", "mapWR", "eachCI", "eachWI" for?
>
>
mapCR : iterate over the characters and replace them by the returned
results (update in-place).
mapWR : iterate over the words and replace them by the returned results
(update in-place).
eachCI : iterate over the characters and return an array of indexed results.
eachCI : iterate over the words and return an array of indexed results.
>
> - functionDoer will get two named arguments "value" and "index" and in
> the case of "reduce" these two arguments will be preceded by an argument
> (frist argument) representing the current value. It would be probably
> helpful for the ooRexx programmer, if "value" was named "item" as this
> is
> the term used in the ooRexx documentation for collections.
>
>
yes. I will change that. Will also apply this change to pipelines.
>
> - ad "filter": what is a filter and where and how can one use it?
>
>
The method ~each lets filter : if no result returned, then no entry added
in the array.
I will commit soon the methods ~select and ~reject which are convenience
methods. You can do the same with ~each, but the block is smaller, just a
boolean expression.
>
> - ad "times", "times.yield", "resume": for which objects are these
> methods defined and what do they do?
>
>
~times and ~times.yield are defined on .String, but works only with numbers
(because do i=self to ...). Execute N times the given block.
~times returns an array of result.
3~times{say arg(1)} -- returns an empty array
3~times{1} -- returns .array~of(1,1,1)
3~times{2*arg(1)} -- returns .array~of(2,4,6)
~times.yield returns a coactivity. You get each result one by one, using
~resume (since a coactivity is a doer, you can also use ~() or ~do)
c = 1000000~times.yield -- default block is {arg(1)}
say c~resume -- 1
say c~resume -- 2
> - ad using block syntax without surrounded by round parentheses: it
> seems that one can state ~map{expression or code with return-statement}
> instead of ~map({expression or code with return-statement}): is this
> intentional (it would break the simple rule that if a method gets an
> argument this argument needs to be enclosed in round parentheses) ? E.g.
> from your readme.txt: "abcdefghijk"~mapC{arg(2)":"arg(1)" "}
>
>
This is intentional, borrowed to Groovy.
http://groovy.codehaus.org/Closures+-+Formal+Definition#Closures-FormalDefinition-SpecialCasePassingClosurestoMethods
f{...} is equivalent to f({...})
f(a1,a2,...){...} is equivalent to f(a1,a2,...,{...})
No space before {
About your note in another mail :
P.S.: @Jean-Louis: in the case that one is supplying an initial value,
the initial value should trail the message-name/RexxBlock-Argument.
This way the first argument is always well defined to be the
messae-name or the RexxBlock object.
You see why the initial value is the first argument : it's to keep the
block as last argument :-)
> - expressions implicitly returning a value: if a RexxBlock only
> consists of an expression, then the result of the expression will be
> returned, e.g. "12"~times({arg(1)/2}) which is the same as
> "12"~times({return arg(1)/2}). This is probably intentional, still thinking
> whether I like it or not (the return-keyword statement is one that every
> Rexx programmer is accustomed to and that explicitly documents what the
> code is supposed to do; not having a return keyword statement should cause
> a runtime error if a result is expected; the implicit return is probably
> not really "Rexxish", although neat in this particular context, which is
> probably restricted to RexxBlocks?).
>
>
I don't add comments, because I have seen your next mails where you
summarize perfectly how it works.
>
> -
>
> A last question related to Pipelines (have not yet come to this corner):
> is this an adaptation of the ooRexx "samples\pipe.rex" where you "just"
> employ closures and coactivities? It looks like that (seems to supply a
> ".do" stage allowing deifning RexxBlocks, which is very powerful; also a
> stage named .inject and .drop? Maybe .console etc.).
>
yes, this is a work derived from pipe.rex. I made a lot of changes... Still
searching my way concerning the management of indexes. Current version in
dropbox has indexes which can be a complex structure. In my sandbox, I have
refactored this part. Now the complex structure is passed through a 3rd
parameter "dataflow", and the indexes become simpler. Not yet commited.
Jean-Louis
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
