On 01.02.2011 17:48, Rick McGuire wrote:
> On Tue, Feb 1, 2011 at 11:46 AM, Mark Miesfeld <miesf...@gmail.com> wrote:
>
>> On Tue, Feb 1, 2011 at 8:28 AM, Sahananda (Jon) Wolfers
>> <sahana...@windhorse.biz> wrote:
>>
>>> I have a feeling that this may already have been asked and answered, but
>>> would this have less of an astonishment factor if the method was makearray -
>>> perhaps with options to indicate the mechanism involved?
>>>
>> Well, as Rick pointed out to me a little while ago, the .String class
>> already has a makearray method, but the semantics for makearray(" ")
>> are not the same for what he was proposing. The treatment of multiple
>> blanks between words is not the same.
>>
> And I am generally opposed to the "add another option to a method"
> solution to make one method name perform different functions.
>
Which IMHO is *not Rexxish* at all, making ooRexx over time more and
more complex to use by increasing the need to memorize more and more
distinct method names, even though they belong/fold semantically together !
As if [oo]Rexx was a signature based language like Java or C# or C++!
(Instead of using parameter types to distinguish different
implementations of a function/method one would use different unique
method/function names instead.)
---
If one looks at the classic Rexx BIFs, having a single function name and
distinguishing the different functionalities by an optional argument
"option" has been very well established and IMHO has been one of the
major contributors of making Rexx so easy to use (and so easy to
memorize the relatively few generic function names). They remained few
exactly for the very reason, that options would indicate what concrete
subfunction should be carried out, picking the default option to be the
one that was expected to be executed most of the time, resp. the one
that the user would expect to be executed.
It would have been possible for classic Rexx to define different
function names to forgo the need for supplying an optional argument, if
a specialized subfunction was desired. An example? Let us take a
simplified "time()"-BIF: instead of "time(option)", where "option" is
one of the strings (only capital letter needed):
1. "Civil", e.g. time("C")
2. "Elapsed", e.g. time("E")
3. "Full", e.g. time("F")
4. "Hours", e.g. time("H")
5. "Long", e.g. time("L")
6. "Minutes", e.g. time("M")
7. "Normal" (default, if option is omitted!), e.g. time("N") or just:
time()
8. "Offset", e.g. time("O")
9. "Reset", e.g. time("R")
10. "Seconds", e.g. time("S")
11. "Ticks", e.g. time("T")
Now signature based functions are not available in Rexx, but one could
simulate them by devsing function names that carry signature based
information like in the case of the time()-BIF (built-in-function), we
merely replace the time()-BIF with the following "self
describing/distinguishing" BIFs:
1. civilTime()
2. elapsedTime()
3. fullTime()
4. hoursTime()
5. longTime()
6. minutesTime()
7. normalTime()
8. offsetTime()
9. resetTime()
10. secondsTime()
11. ticksTime()
So now we have exploded the single time()-BIF into eleven (!) distinct
time functions instead (each without an option) !
Furthermore these eleven functions need to be spelled out exactly as
written/shown or we would get a runtime error, of course! No means
available to abbreviate the function names. (Demanding programmers that
type well and who are equipped with spell-checker and word-completion
editors for Rexx.)
It would have been possible in classic Rexx, but it was not done - why ?
Rather, the option names were mostlikely picked thoroughly such, that
they were self-describing and that the first letter was able to
distinguish the desired option (subfunction). Many of these options can
be guessed/inferred by the programmers, allowing to forgo the need to
look up the reference documentation in the general case.
This way it has been only necessary to remember the generic function
name "time()" and only if some untypical rendering from the time()-BIF
was needed, did it become necessary to supply the option to indicate
which subfunction was desired from the BIF instead.
In this context syntax diagrams are very helpful for documenting the
BIFs with their options.
---
The same principles apply when designing method names for classes.
If one takes a lot of time to thoroughly name (and design) a method, the
options that should be made available and then to decide which option
would be the most used one, then it might become easy on programmers to
guess/infer the name of a desired method. If some special
rendering/functionality/behaviour is desired, which is not generic, then
supplying an option argument to indicate exactly the specialized
behaviour would be exactly the same as for the Rexx BIFs.
Or with other words: this task of picking a method name and devise the
names of its options would be directly comparable with designing the
classic Rexx BIFs.
---
Working with students who freshly learned ooRexx, it is one major
problem for them to memorize all the methods that are available in
classes. The more methods a class possesses the more complex it becomes
for them to gain and retain an overview and being able to employ/recall
them correctly without looking up the ooRexx reference all the time.
(Folding closely related methods into a generic method with options,
thereby reducing the number of methods, would help a lot in such cases,
IMHO!)
---rony
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
