I made a side-by-side comparison of String with MutableBuffer. 100 methods
on one side, 13 methods on the other side...(sigh:-)
See attached .txt file.
Some assumptions :
The (abbutal) and (blank) operators are candidate for implementation on
MutableBuffer. Works like APPEND.
Transitivity is
Sorry for the mess of my previous mail... When looking at the SourceForge
mail archive, I see the contents of the attached file (it was not my
intent !).
And the main body of the mail does not appear... I use Lotus Notes from
work.
Jean Louis
CSC Financial Services SAS
Registered Office: 14
RexxObject::classInstance is not the variable I highlighted as bad.
RexxObject::operatorMethods was the one that looked suspect in your
last post.
Rick
On Wed, Jul 23, 2008 at 10:35 AM, Moritz Hoffmann [EMAIL PROTECTED] wrote:
On Wed, 23 Jul 2008 08:23:39 -0400
Rick McGuire [EMAIL PROTECTED]
On Wed, Jul 23, 2008 at 10:18 AM, Rick McGuire [EMAIL PROTECTED] wrote:
I've fixed both the concurrenty issues and the rexxhide crash.
Yes, I just saw those. Thanks.
I like the fix to the standard I/O handles. That looks much cleaner.
--
Mark Miesfeld
David Crayford wrote:
Right! m4 is the big issue! If you know of any mainframe ports of m4
1.4.11, even if it's z/VM, I would be
very interested to hear about it.
ISTR that I compiled it under OVM some years ago.
BTW, the patches IBM made when porting
the GNU build system
to z/OS never made
If you want to return nothing, then declare the return type as
RexxObjectPtr and return NULLOBJECT. This will only raise an error if
the method is used in an expression context. For example,
say x~'STATE='(1)
Would return raise an error, but
x~state=1
would not.
A VOID return type just
On Wed, Jul 23, 2008 at 10:39 AM, Rick McGuire [EMAIL PROTECTED] wrote:
If you want to return nothing, then declare the return type as
RexxObjectPtr and return NULLOBJECT.
I think that works well. Your idea of having a type like
NORETURNVALUE is good, and I was wondering if you had something
