From: Rick M. <obj...@gm...> - 2008-09-26 14:40:37
|
The exercise of writing test cases for the various APIs was an interesting process, as it gave me the opportunity to reassess whether APIs belonged in the set and also pointed out some holes where additional APIs should be provided. In the process of doing this, I started to question whether the Table set of APIs even belong on the list. The initial list of APIs was created be drawing upon the old (non-documented) internal object API augmented by my best guess on what additional operations might be needed. As things progressed, I've eliminated a few of the old API holdovers because they didn't really provide any added value or overlapped with other means of doing the same things. NewObject() and NewInteger() are two examples. One rule of thumb I've started applying to the APIs is to recognize that most of the operations in the APIs can be accomplished using the generic SendMessage() API call. However, the API versions make it easier (and more efficient) for the C programmer. for example, ArrayAt() allows a size_t value to be specified for the array index rather than require the size be converted to a Rexx object first, which would be the case if you had to use SendMessage(). If you apply that rule of thumb to the table APIs (TablePut(), TableAt(), TableRemove(), NewTable(), and IsTable()), the only one of these that doesn't map directly into a SendMessage() call is IsTable(), and that one is only required because we have the other set. I'm proposing that these APIs and the associated RexxTableObject type be removed from the API set because there's no real added value to having these APIs. Rick |
From: Mark M. <mie...@gm...> - 2008-09-26 15:57:12
|
On Fri, Sep 26, 2008 at 7:40 AM, Rick McGuire <obj...@gm...> wrote: > The exercise of writing test cases for the various APIs was an > interesting process, as it gave me the opportunity to reassess whether > APIs belonged in the set and also pointed out some holes where > additional APIs should be provided. I've been watching your test cases and interleaving commits to the interpreter and could see that was what you were doing. <grin> > In the process of doing this, I started to question whether the Table > set of APIs even belong on the list. I like the ability to use Table objects in the external methods / functions rather than stems. I especially like being able to return a Table object. However, if you think using SendMessage is just as efficient in the C / C++ code, then removing the Table APIs seems fine to me. What happens when you are returning a Table object from a API method? It would be returned as a RexxObject. Would it just then work as expected in the Rexx code? Is that less efficient? -- Mark Miesfeld |
From: Rick M. <obj...@gm...> - 2008-10-04 23:00:31
|
On Fri, Sep 26, 2008 at 11:57 AM, Mark Miesfeld <mie...@gm...> wrote: > On Fri, Sep 26, 2008 at 7:40 AM, Rick McGuire <obj...@gm...> wrote: > >> The exercise of writing test cases for the various APIs was an >> interesting process, as it gave me the opportunity to reassess whether >> APIs belonged in the set and also pointed out some holes where >> additional APIs should be provided. > > I've been watching your test cases and interleaving commits to the > interpreter and could see that was what you were doing. <grin> > >> In the process of doing this, I started to question whether the Table >> set of APIs even belong on the list. > > I like the ability to use Table objects in the external methods / > functions rather than stems. I especially like being able to return a > Table object. I think in the places where you were returning a table object, a directory object is really the more appropriate choice. In general, if all of your keys are strings, a directory would be preferred over a table...and using a directory from the APIs is more efficient generally since you can use CSTRING arguments for the keys. > > However, if you think using SendMessage is just as efficient in the C > / C++ code, then removing the Table APIs seems fine to me. What really counts is the number of times you have to cross the external/internal boundary. Since the number of SendMessage() calls is the same, and what you do with the arguments is the same, the efficiency is basically the same. contrast this with something like ArrayAt(), where you are able to directly pass in the array index as a binary value rather than creating an object from the number, calling SendMessage() so that the interpreter can turn that object back into a binary index. The API allows you to cut a few corners. > > What happens when you are returning a Table object from a API method? > It would be returned as a RexxObject. Would it just then work as > expected in the Rexx code? Is that less efficient? Yes, just return it is as a RexxObjectPtr. There is no loss in efficiency. In fact, any of the specific types used as return types are handled by the same element in the switch statement. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------- > 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: Rick M. <obj...@gm...> - 2008-09-26 17:07:48
|
I did discover that Mark is using the table apis in a couple of places in the oodialog code. However, since he's using strings as indexes, a directory would probably be more appropriate (and easier) to use. Rick On Fri, Sep 26, 2008 at 12:58 PM, David Ashley <da...@us...> wrote: > I agree with your analysis. I can not see that I would ever use the table > APIs. Mainly because they do not map to typical C/C++ structure analogs. > > Thanks, > W. David Ashley > IBM Systems and Technology Group Lab Services > Open Object Rexx Team > Mobile Phone: 512-289-7506 > > > "Rick McGuire" ---09/26/2008 11:54:37 AM---The exercise of writing test > cases for the various APIs was an > > "Rick McGuire" <obj...@gm...> > > 09/26/2008 09:40 AM > > Please respond to > Open Object Rexx Developer Mailing List <oor...@li...> > > To > "Open Object Rexx Developer Mailing List" > <oor...@li...> > cc > > Subject > [Oorexx-devel] Removing the table APIs from the API set. > The exercise of writing test cases for the various APIs was an > interesting process, as it gave me the opportunity to reassess whether > APIs belonged in the set and also pointed out some holes where > additional APIs should be provided. > > In the process of doing this, I started to question whether the Table > set of APIs even belong on the list. The initial list of APIs was > created be drawing upon the old (non-documented) internal object API > augmented by my best guess on what additional operations might be > needed. As things progressed, I've eliminated a few of the old API > holdovers because they didn't really provide any added value or > overlapped with other means of doing the same things. NewObject() and > NewInteger() are two examples. > > One rule of thumb I've started applying to the APIs is to recognize > that most of the operations in the APIs can be accomplished using the > generic SendMessage() API call. However, the API versions make it > easier (and more efficient) for the C programmer. for example, > ArrayAt() allows a size_t value to be specified for the array index > rather than require the size be converted to a Rexx object first, > which would be the case if you had to use SendMessage(). > > If you apply that rule of thumb to the table APIs (TablePut(), > TableAt(), TableRemove(), NewTable(), and IsTable()), the only one of > these that doesn't map directly into a SendMessage() call is > IsTable(), and that one is only required because we have the other > set. I'm proposing that these APIs and the associated RexxTableObject > type be removed from the API set because there's no real added value > to having these APIs. > > Rick > > ------------------------------------------------------------------------- > 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 > Oor...@li... > 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |
From: Mark M. <mie...@gm...> - 2008-10-04 17:12:57
|
All of a sudden some of these old messages and svn notices are showing up. -- Mark Miesfeld On Fri, Sep 26, 2008 at 10:07 AM, Rick McGuire <obj...@gm...> wrote: > I did discover that Mark is using the table apis in a couple of places > in the oodialog code. However, since he's using strings as indexes, a > directory would probably be more appropriate (and easier) to use. > > Rick > > On Fri, Sep 26, 2008 at 12:58 PM, David Ashley <da...@us...> wrote: >> I agree with your analysis. I can not see that I would ever use the table >> APIs. Mainly because they do not map to typical C/C++ structure analogs. >> >> Thanks, >> W. David Ashley >> IBM Systems and Technology Group Lab Services >> Open Object Rexx Team >> Mobile Phone: 512-289-7506 >> >> >> "Rick McGuire" ---09/26/2008 11:54:37 AM---The exercise of writing test >> cases for the various APIs was an >> >> "Rick McGuire" <obj...@gm...> >> >> 09/26/2008 09:40 AM >> >> Please respond to >> Open Object Rexx Developer Mailing List <oor...@li...> >> >> To >> "Open Object Rexx Developer Mailing List" >> <oor...@li...> >> cc >> >> Subject >> [Oorexx-devel] Removing the table APIs from the API set. >> The exercise of writing test cases for the various APIs was an >> interesting process, as it gave me the opportunity to reassess whether >> APIs belonged in the set and also pointed out some holes where >> additional APIs should be provided. >> >> In the process of doing this, I started to question whether the Table >> set of APIs even belong on the list. The initial list of APIs was >> created be drawing upon the old (non-documented) internal object API >> augmented by my best guess on what additional operations might be >> needed. As things progressed, I've eliminated a few of the old API >> holdovers because they didn't really provide any added value or >> overlapped with other means of doing the same things. NewObject() and >> NewInteger() are two examples. >> >> One rule of thumb I've started applying to the APIs is to recognize >> that most of the operations in the APIs can be accomplished using the >> generic SendMessage() API call. However, the API versions make it >> easier (and more efficient) for the C programmer. for example, >> ArrayAt() allows a size_t value to be specified for the array index >> rather than require the size be converted to a Rexx object first, >> which would be the case if you had to use SendMessage(). >> >> If you apply that rule of thumb to the table APIs (TablePut(), >> TableAt(), TableRemove(), NewTable(), and IsTable()), the only one of >> these that doesn't map directly into a SendMessage() call is >> IsTable(), and that one is only required because we have the other >> set. I'm proposing that these APIs and the associated RexxTableObject >> type be removed from the API set because there's no real added value >> to having these APIs. >> >> Rick >> >> ------------------------------------------------------------------------- >> 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 >> Oor...@li... >> 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 >> Oor...@li... >> 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |