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 Place de la Coupole, Axe Liberté, 94220 Charenton Le
Pont, France
Registered in France: RCS Créteil B 323 127 332
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Jean-Louis Faucher/FSG/[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
23/07/2008 09:11
Please respond to
Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
To
Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
cc
Subject
[Oorexx-devel] Migration of String methods to MutableBuffer (was : Re:
Deferred evaluation of arguments ?)
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 supported because these operators return the receiver
object, like APPEND :
myBuffer"abbutal" "blank" --> both strings are appended to the buffer.
For the other methods which return a String, it's difficult (to me) to
decide if the MutableBuffer should be modified in place, or if a String
should be returned.
SUBSTR (which is already implemented) returns a String. I think it should
be the same for MAKESTRING, LEFT, RIGHT, B2X, C2X, D2C, D2X, X2B, X2C,
CENTER, CENTRE, DECODEBASE64, ENCODEBASE64, FORMAT.
INSERT and OVERLAY (which are already implemented) modify the buffer.
Should be the same for CHANGESTR, DELSTR, DELWORD, LOWER, REVERSE, UPPER,
TRANSLATE. Is it also the case for BITAND, BITOR, BITXOR, COPIES, SPACE,
STRIP ?
It seems that all the String methods can be implemented on MutableBuffer.
At term, should MutableBuffer be a subclass of String ?
Concerning the implementation files to modify, a look at previous commits
indicates that these files must be updated :
kernel/classes/MutableBufferClass.cpp
kernel/classes/MutableBufferClass.hpp
kernel/runtime/Setup.cpp
I suppose test/trunk/ooRexx/base/class/String can be reused and adapted
for MutableBuffer.
I will try to migrate the method CHANGESTR. In case of success, what is
the procedure to submit a patch ? I have zero experience on that... I use
TortoiseSVN and I see a menu "Create patch" which lets select several
files, sounds good.
Jean Louis
Veuillez répondre à Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
Envoyé par : [EMAIL PROTECTED]
Pour : "Open Object Rexx Developer Mailing List"
<oorexx-devel@lists.sourceforge.net>
cc :
Objet : Re: [Oorexx-devel] Deferred evaluation of arguments ?
Well, the RFE tracker is a good place to start:
http://sourceforge.net/tracker/?group_id=119701&atid=684733
You can assume that anything with me as the submitter can be
considered one of the "well-thought-out" ideas. I have one area in
mind thought that I'd like to see in 4.0 and it's not really
disruptive. I would like to add a lot of the string methods to the
MutableBuffer class. Any of the methods that don't alter the buffer
(searches, compares, etc.) can share code with the string class for
the actual implementation. We've started this process already with
some of the string methods (pos, lastpos, substr) by moving the
substring code to a static method in the StringUtil class and making
the String and MutableBuffer equivalent methods just stubs that call
the shared code using a data pointer and length rather than the this
pointer.
Migrating these methods are a good starting point. You can do them
one at a time and submit patches....and multiple people can work on
this task at the same time as well. Once you get a few under your
belt, you might feel up to the task of tackling mutablebuffer methods
that change the data as well. ChangeStr() is an obvious one to want.
Rick
On Tue, Jul 22, 2008 at 7:21 AM, Jean-Louis Faucher <[EMAIL PROTECTED]>
wrote:
>
> Thanks Rick,
>
> I was limited to passing arguments, but it's true that the problem is
> wider... I had the Lisp approach in mind (fsubr), but the Smalltalk
approach
> based on code blocks is also a candidate approach, and probably
others... (I
> have only a superficial knowledge of these subjects :-)
>
> David was faster than me : Is it possible to have the list of
well-defined
> enhancements on your todo list ?
>
> Jean Louis
>
>
>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to
> any order or other contract unless pursuant to explicit written
agreement or
> government initiative expressly permitting the use of e-mail for such
> purpose.
>
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>
> David Crayford <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
>
> 22/07/2008 13:15
>
> Please respond to
> Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
> To
> Open Object Rexx Developer Mailing List
<oorexx-devel@lists.sourceforge.net>
> cc
> Subject
> Re: [Oorexx-devel] Deferred evaluation of arguments ?
>
>
>
>
> I love closures! I've only used them hacking about in groovy but they're
> really nice. What else is on your todo list? Have you
> given aspects any thought?
>
> Rick McGuire wrote:
>> I've been giving some thought to whether closures could be added to
>> the language for some time, but the issues generally lie on the
>> calling end. That is, what is the syntax to be used that would allow
>> a closure to be created without cluttering up the language with lots
>> of special exceptions or awkward syntax. Ideally, a closure would be
>> something that would just be an extension of normal expression syntax.
>> Closures would be assignable to variables and, of course. allowed as
>> method arguments. Implemented that way, there's no additional
>> overhead needed on the argument calling mechanisms. So far, I've not
>> found a syntax that I'm happy with.
>>
>> There are other side issues that need to be addressed, such as
>> ensuring that the closure somehow becomes invalid when the environment
>> where it was created is no longer valid, or the more interesting case
>> of a closure passed to a method that does an early reply...now the
>> closure will be executed on an entirely different thread.
>>
>> This is an interesting idea, but not one I'm prepared to jump on and
>> accept until all of the implications are written down and discussed.
>> Right now, there are lots of more well-defined enhancements on my todo
>> list. If you'd like to get involved in any of these, just speak up
>> and I'll suggest a few.
>>
>> Rick
>>
>> On Tue, Jul 22, 2008 at 5:01 AM, Jean-Louis Faucher <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Sorry, my previous mail was sent from a flashmail, was a bad idea ! I
>>> hope
>>> this one will be more readable...
>>>
>>> As other users (see comp.lang.rexx/2005-11/msg00065.html), I use
>>> sometimes a
>>> function iif which on the basis of a condition selects between two
values
>>> :
>>> iif:
>>> use strict arg condition, iftrue, iffalse
>>> if condition then
>>> interpret "return" iftrue
>>> else
>>> interpret "return" iffalse
>>>
>>> I see two drawbacks with this function :
>>> The caller must surround the 2nd and 3rd argument by quotes, to pass a
>>> string to the function. Example : say iif(s == .nil, 's', 's~id')
>>> The whole scope of the caller must be visible, to let the evaluation
have
>>> access to all the variables of the caller. So I can't implement this
>>> function as a procedure or a routine or a method. And I can't put it
in
>>> my
>>> library that I requires from my scripts.
>>>
>>> I had a look at the function RexxActivation::run (putting a breakpoint
>>> here
>>> is very instructive).
>>> I see that each instruction is evaluated by : nextInst->execute(this,
>>> localStack)
>>> It seems that each instruction is in charge of the evaluation of its
>>> arguments, using : result = this->expression->evaluate(context, stack)
>>>
>>> Could we imagine that such a behavior is possible at the level of user
>>> rexx
>>> code ? The not-evaluated-expression passed to the rexx code should
bring
>>> the
>>> context and stack with her, to let the user write
>>> expression->evaluate()
>>>
>>> A not-evaluated-expression is not of type String. Should be of a new
type
>>> (Closure ?) which supports the method evaluate().
>>>
>>> Example :
>>>
>>> iif: procedure
>>> use unevaluated arg condition, iftrue, iffalse
>>> if condition->evaluate() then
>>> return iftrue->evaluate()
>>> else
>>> return iffalse->evaluate()
>>>
>>> Here " unevaluated " is a keyword to indicate the deferred evaluation
of
>>> the
>>> arguments.
>>> I can use a procedure or routine or method since the evaluation of the
>>> expression is done in the caller's context.
>>>
>>> The caller calls the function without surrounding the expressions in
>>> quotes
>>> :
>>> say iif(s == .nil, s, s~id)
>>>
>>> And there is no error like Object "The NIL object" does not understand
>>> message "ID" when s is nil.
>>>
>>> Jean Louis
>>>
>>>
-------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>>
>>>
>>
>>
-------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
>
>
-------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
-------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[attachment "String vs MutableBuffer.txt" deleted by Jean-Louis
Faucher/FSG/CSC]
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
