implementing comparable & adding serialversion to Rexx (the class, not the language)
Locked
 
|
Let me float this thought for possible inclusion in 3.02:
I use the Java Collection classes a lot. I have a class RexxComparator handy to make sure I can add Rexx objects to instances of Map (these need to be orderable, so Comparable). How about adding its methods and the interface signature for Comparable to the Rexx class? === /** * Class RexxComparator is a Comparator that gives us the possibility * to use Rexx Strings in Collection classes without encountering * exceptions when using Collections.sort(). It implements the compare * method of the Comparator interface. * @version $Id: RexxComparator.nrx,v 1.1 2009/06/18 15:50:30 ja3878 Exp $ */ class RexxComparator implements Comparator,Serializable properties constant serialVersionUID = long 991920429 method RexxComparator() super() /** * method compare returns a negative if the first argument is * smaller than the second, and a positive number when it is * bigger. * @param i1 the first String * @param i2 the second String * @return int -1 if i1 < i2, +1 if i1 > i2 */ method compare(i1=Object, i2=Object) returns int i = Rexx i1 j = Rexx i2 if i < j then return -1 if i > j then return +1 else return 0 === The Rexx class itself is already serializable, but lacks a long serialVersionID, and this leads to RMI exceptions whenever the language runtime is recompiled. To minimize these occurances, we could add it, and only change it when we really have updated the Rexx class. With infrequent updates, this is manageable, but if we are going to release more often it will be a burden on RMI users with deployed applications if we have this chance more than necessary. Let me know what you think. best regards, René Jansen _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
Hello Rene, and all,
1.) I did get -- long time ago -- thankfully a prior version of your RexxComparator Class *and* do use it since for SORTING my symbol tables, etc. 2.) You did obviously meanwhile add Serializable, too. 3.) I think RexxComparator should be in NetRexxR.jar *and* NetRexxC.jar, when possible in the 3.01 final distrribution (or 3.02, as the ARB feels appropriate) Kind regards from again sunny Vienna, Thomas. ========================================================== Am 17.10.2011 09:51, schrieb rvjansen: > Let me float this thought for possible inclusion in 3.02: > > I use the Java Collection classes a lot. I have a class RexxComparator > handy to make sure I can add Rexx objects to instances of Map (these > need to be orderable, so Comparable). How about adding its methods and > the interface signature for Comparable to the Rexx class? > === > /** > * Class RexxComparator is a Comparator that gives us the possibility > * to use Rexx Strings in Collection classes without encountering > * exceptions when using Collections.sort(). It implements the compare > * method of the Comparator interface. > * @version $Id: RexxComparator.nrx,v 1.1 2009/06/18 15:50:30 ja3878 > Exp $ > */ > class RexxComparator implements Comparator,Serializable > > properties constant > serialVersionUID = long 991920429 > > method RexxComparator() > super() > > /** > * method compare returns a negative if the first argument is > * smaller than the second, and a positive number when it is > * bigger. > * @param i1 the first String > * @param i2 the second String > * @return int -1 if i1 < i2, +1 if i1 > i2 > */ > method compare(i1=Object, i2=Object) returns int > i = Rexx i1 > j = Rexx i2 > > if i < j then return -1 > if i > j then return +1 > else return 0 > === > > The Rexx class itself is already serializable, but lacks a long > serialVersionID, and this leads to RMI exceptions whenever the > language runtime is recompiled. To minimize these occurances, we could > add it, and only change it when we really have updated the Rexx class. > With infrequent updates, this is manageable, but if we are going to > release more often it will be a burden on RMI users with deployed > applications if we have this chance more than necessary. > > Let me know what you think. > > best regards, > > René Jansen > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
|
|
In reply to this post by rvjansen
For completeness, there should be also a class RexxStrictComparator
with the same parameters, etc, but using the operators '<<' and '>>' in the actual code. I do also have the opinion this function should be part of the run-time-pckage! Thomas. ========================================================== Am 17.10.2011 09:51, schrieb rvjansen: > Let me float this thought for possible inclusion in 3.02: > > I use the Java Collection classes a lot. I have a class RexxComparator > handy to make sure I can add Rexx objects to instances of Map (these > need to be orderable, so Comparable). How about adding its methods and > the interface signature for Comparable to the Rexx class? > === > /** > * Class RexxComparator is a Comparator that gives us the possibility > * to use Rexx Strings in Collection classes without encountering > * exceptions when using Collections.sort(). It implements the compare > * method of the Comparator interface. > * @version $Id: RexxComparator.nrx,v 1.1 2009/06/18 15:50:30 ja3878 > Exp $ > */ > class RexxComparator implements Comparator,Serializable > > properties constant > serialVersionUID = long 991920429 > > method RexxComparator() > super() > > /** > * method compare returns a negative if the first argument is > * smaller than the second, and a positive number when it is > * bigger. > * @param i1 the first String > * @param i2 the second String > * @return int -1 if i1 < i2, +1 if i1 > i2 > */ > method compare(i1=Object, i2=Object) returns int > i = Rexx i1 > j = Rexx i2 > > if i < j then return -1 > if i > j then return +1 > else return 0 > === > > The Rexx class itself is already serializable, but lacks a long > serialVersionID, and this leads to RMI exceptions whenever the > language runtime is recompiled. To minimize these occurances, we could > add it, and only change it when we really have updated the Rexx class. > With infrequent updates, this is manageable, but if we are going to > release more often it will be a burden on RMI users with deployed > applications if we have this chance more than necessary. > > Let me know what you think. > > best regards, > > René Jansen > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > -- Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
Re: implementing comparable & adding serialversion to Rexx (the class, not the language)
|
|
In reply to this post by rvjansen
René -
How about opening an issue on Kenai for this one? Offhand it looks doable. In fact it might be possible to implement Collection as well so that a Rexx object could be a collection itself as well as a member of a collection. George - Does CLDC have collections stuff or would that require an adapter? -- Kermit On 10/17/2011 12:51 AM, rvjansen wrote: > Let me float this thought for possible inclusion in 3.02: > > I use the Java Collection classes a lot. I have a class RexxComparator > handy to make sure I can add Rexx objects to instances of Map (these > need to be orderable, so Comparable). How about adding its methods and > the interface signature for Comparable to the Rexx class? > === > /** > * Class RexxComparator is a Comparator that gives us the possibility > * to use Rexx Strings in Collection classes without encountering > * exceptions when using Collections.sort(). It implements the compare > * method of the Comparator interface. > * @version $Id: RexxComparator.nrx,v 1.1 2009/06/18 15:50:30 ja3878 > Exp $ > */ > class RexxComparator implements Comparator,Serializable > > properties constant > serialVersionUID = long 991920429 > > method RexxComparator() > super() > > /** > * method compare returns a negative if the first argument is > * smaller than the second, and a positive number when it is > * bigger. > * @param i1 the first String > * @param i2 the second String > * @return int -1 if i1 < i2, +1 if i1 > i2 > */ > method compare(i1=Object, i2=Object) returns int > i = Rexx i1 > j = Rexx i2 > > if i < j then return -1 > if i > j then return +1 > else return 0 > === > > The Rexx class itself is already serializable, but lacks a long > serialVersionID, and this leads to RMI exceptions whenever the > language runtime is recompiled. To minimize these occurances, we could > add it, and only change it when we really have updated the Rexx class. > With infrequent updates, this is manageable, but if we are going to > release more often it will be a burden on RMI users with deployed > applications if we have this chance more than necessary. > > Let me know what you think. > > best regards, > > René Jansen > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
yes, will do. We also should document these constraints - like the
oneThomas mentioned, of not using Rexx runtime operators, and also not using the Rexx runtime in the translator itself. I'll add them in the wiki. If you see more of these mentioned in the sourcecode, please also add them to the wiki. best regards, René Jansen. On Mon, 17 Oct 2011 02:07:02 -0700, Kermit Kiser wrote: > René - > > How about opening an issue on Kenai for this one? > > Offhand it looks doable. In fact it might be possible to implement > Collection as well so that a Rexx object could be a collection itself > as well as a member of a collection. > > George - Does CLDC have collections stuff or would that require an > adapter? > > -- Kermit > > > On 10/17/2011 12:51 AM, rvjansen wrote: >> Let me float this thought for possible inclusion in 3.02: >> >> I use the Java Collection classes a lot. I have a class >> RexxComparator handy to make sure I can add Rexx objects to instances >> of Map (these need to be orderable, so Comparable). How about adding >> its methods and the interface signature for Comparable to the Rexx >> class? >> === >> /** >> * Class RexxComparator is a Comparator that gives us the >> possibility >> * to use Rexx Strings in Collection classes without encountering >> * exceptions when using Collections.sort(). It implements the >> compare >> * method of the Comparator interface. >> * @version $Id: RexxComparator.nrx,v 1.1 2009/06/18 15:50:30 ja3878 >> Exp $ >> */ >> class RexxComparator implements Comparator,Serializable >> >> properties constant >> serialVersionUID = long 991920429 >> >> method RexxComparator() >> super() >> >> /** >> * method compare returns a negative if the first argument is >> * smaller than the second, and a positive number when it is >> * bigger. >> * @param i1 the first String >> * @param i2 the second String >> * @return int -1 if i1 < i2, +1 if i1 > i2 >> */ >> method compare(i1=Object, i2=Object) returns int >> i = Rexx i1 >> j = Rexx i2 >> >> if i < j then return -1 >> if i > j then return +1 >> else return 0 >> === >> >> The Rexx class itself is already serializable, but lacks a long >> serialVersionID, and this leads to RMI exceptions whenever the >> language runtime is recompiled. To minimize these occurances, we could >> add it, and only change it when we really have updated the Rexx class. >> With infrequent updates, this is manageable, but if we are going to >> release more often it will be a burden on RMI users with deployed >> applications if we have this chance more than necessary. >> >> Let me know what you think. >> >> best regards, >> >> René Jansen >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> >> >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: implementing comparable & adding serialversion to Rexx (the class, not the language)
|
|
In reply to this post by Kermit Kiser
Kermit,
Re CLDC: The available collection classes are just java.util.Vector java.util.Stack java.util.Hashtable java.util.Enumeration (interface) These were judged by the CLDC committee to be a suitable compromise between size and capability. [And adding Indexed Strings dramatically improves capability.] However, adding collection class support to NetRexxR may not mean that my SHAP package must disconnect from further NetRexx developments. My understanding of the construction of NetRexxR [and I hope that Mike will see this and comment] is that it has been carefully partitioned so that the modules support specific features. For example, if neither Say nor Ask is used in a program, RexxIO will not be loaded, if there are no Parse statement, RexxParse is left out, etc. It would seem that if the collection class support can be similarly structured, then it would be harmless to CLDC. In fact, I'm not certain that those classes would be unusable -- byte code is, after all, a very compact representation of classes. And SHAP is specifically aimed at implementation in Field Programmable Gate Array (FPGA) boards; even the simplest of these has several times the memory envisioned by CLDC. George On Mon, Oct 17, 2011 at 5:07 AM, Kermit Kiser <[hidden email]> wrote: René - _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
RE: implementing comparable & adding serialversion toRexx (the class, not the language)
|
|
George, yes, you have it right. One has to be careful
when adding things that one doesn't drag in kilobytes of unwanted classes.
Not too important on broadband, but still important for mobile and embedded in
general.
Equally, file I/O is bad news .. whenever FireFox
starts up (for example) there is so much disk activity -- which AVG then
checks -- that my quite powerful laptop locks up for 5-9 seconds.
'compare' sounds reasonably benign, though .. interface
classes are generally small. But perhaps might be worth finding a tool
that allows one to see how many bytes are pulled in on startup, to see the real
effect of such a change.
Mike
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: implementing comparable & adding serialversion to Rexx (the class, not the language)
|
|
In reply to this post by George Hovey-2
Actually George, I was mainly thinking about whether or not adding
the interfaces "Collection" or "Comparable" to class Rexx would
cause a problem for CLDC, but the presence of some collections
classes sort of implies that the interfaces would be there right?
-- Kermit On 10/17/2011 8:42 AM, George Hovey wrote: Kermit, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: implementing comparable & adding serialversion to Rexx (the class, not the language)
|
|
On Mon, Oct 17, 2011 at 12:46 PM, Kermit Kiser <[hidden email]> wrote:
> Actually George, I was mainly thinking about whether or not adding the > interfaces "Collection" or "Comparable" to class Rexx would cause a problem > for CLDC, but the presence of some collections classes sort of implies that > the interfaces would be there right? If I remember correctly, the collection classes in CLDC are not the same as the ones in the full j2se stack. In particular, they did not implement the interfaces that were introduced with the collections hierarchy. Of course, introducing Collection will end up pulling in Iterator also. Not sure there are any others that might get dragged in. Rick > > -- Kermit > > > On 10/17/2011 8:42 AM, George Hovey wrote: > > Kermit, > > Re CLDC: The available collection classes are just > > java.util.Vector > java.util.Stack > java.util.Hashtable > java.util.Enumeration (interface) > > These were judged by the CLDC committee to be a suitable compromise between > size and capability. [And adding Indexed Strings dramatically improves > capability.] > > However, adding collection class support to NetRexxR may not mean that my > SHAP package must disconnect from further NetRexx developments. My > understanding of the construction of NetRexxR [and I hope that Mike will see > this and comment] is that it has been carefully partitioned so that the > modules support specific features. For example, if neither Say nor Ask is > used in a program, RexxIO will not be loaded, if there are no Parse > statement, RexxParse is left out, etc. > > It would seem that if the collection class support can be similarly > structured, then it would be harmless to CLDC. In fact, I'm not certain > that those classes would be unusable -- byte code is, after all, a very > compact representation of classes. And SHAP is specifically aimed at > implementation in Field Programmable Gate Array (FPGA) boards; even the > simplest of these has several times the memory envisioned by CLDC. > > George > > On Mon, Oct 17, 2011 at 5:07 AM, Kermit Kiser <[hidden email]> > wrote: >> >> René - >> >> How about opening an issue on Kenai for this one? >> >> Offhand it looks doable. In fact it might be possible to implement >> Collection as well so that a Rexx object could be a collection itself as >> well as a member of a collection. >> >> George - Does CLDC have collections stuff or would that require an >> adapter? >> >> -- Kermit >> >> >> On 10/17/2011 12:51 AM, rvjansen wrote: >>> >>> Let me float this thought for possible inclusion in 3.02: >>> >>> I use the Java Collection classes a lot. I have a class RexxComparator >>> handy to make sure I can add Rexx objects to instances of Map (these need to >>> be orderable, so Comparable). How about adding its methods and the interface >>> signature for Comparable to the Rexx class? >>> === >>> /** >>> * Class RexxComparator is a Comparator that gives us the possibility >>> * to use Rexx Strings in Collection classes without encountering >>> * exceptions when using Collections.sort(). It implements the compare >>> * method of the Comparator interface. >>> * @version $Id: RexxComparator.nrx,v 1.1 2009/06/18 15:50:30 ja3878 Exp >>> $ >>> */ >>> class RexxComparator implements Comparator,Serializable >>> >>> properties constant >>> serialVersionUID = long 991920429 >>> >>> method RexxComparator() >>> super() >>> >>> /** >>> * method compare returns a negative if the first argument is >>> * smaller than the second, and a positive number when it is >>> * bigger. >>> * @param i1 the first String >>> * @param i2 the second String >>> * @return int -1 if i1 < i2, +1 if i1 > i2 >>> */ >>> method compare(i1=Object, i2=Object) returns int >>> i = Rexx i1 >>> j = Rexx i2 >>> >>> if i < j then return -1 >>> if i > j then return +1 >>> else return 0 >>> === >>> >>> The Rexx class itself is already serializable, but lacks a long >>> serialVersionID, and this leads to RMI exceptions whenever the language >>> runtime is recompiled. To minimize these occurances, we could add it, and >>> only change it when we really have updated the Rexx class. With infrequent >>> updates, this is manageable, but if we are going to release more often it >>> will be a burden on RMI users with deployed applications if we have this >>> chance more than necessary. >>> >>> Let me know what you think. >>> >>> best regards, >>> >>> René Jansen >>> >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >>> >>> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: implementing comparable & adding serialversion to Rexx (the class, not the language)
|
|
Thanks Rick. That was indeed what I was wondering based on the fact that
the classes George listed were around in "pre-collections" days. However, that does not necessarily imply a problem for CLDC does it? It seems to me that the missing interfaces could be added to whatever adapter code George creates without adding much to it's size. -- Kermit On 10/17/2011 10:14 AM, Rick McGuire wrote: > On Mon, Oct 17, 2011 at 12:46 PM, Kermit Kiser<[hidden email]> wrote: >> Actually George, I was mainly thinking about whether or not adding the >> interfaces "Collection" or "Comparable" to class Rexx would cause a problem >> for CLDC, but the presence of some collections classes sort of implies that >> the interfaces would be there right? > If I remember correctly, the collection classes in CLDC are not the > same as the ones in the full j2se stack. In particular, they did not > implement the interfaces that were introduced with the collections > hierarchy. Of course, introducing Collection will end up pulling in > Iterator also. Not sure there are any others that might get dragged > in. > > Rick > >> -- Kermit >> >> >> On 10/17/2011 8:42 AM, George Hovey wrote: >> >> Kermit, >> >> Re CLDC: The available collection classes are just >> >> java.util.Vector >> java.util.Stack >> java.util.Hashtable >> java.util.Enumeration (interface) >> >> These were judged by the CLDC committee to be a suitable compromise between >> size and capability. [And adding Indexed Strings dramatically improves >> capability.] >> >> However, adding collection class support to NetRexxR may not mean that my >> SHAP package must disconnect from further NetRexx developments. My >> understanding of the construction of NetRexxR [and I hope that Mike will see >> this and comment] is that it has been carefully partitioned so that the >> modules support specific features. For example, if neither Say nor Ask is >> used in a program, RexxIO will not be loaded, if there are no Parse >> statement, RexxParse is left out, etc. >> >> It would seem that if the collection class support can be similarly >> structured, then it would be harmless to CLDC. In fact, I'm not certain >> that those classes would be unusable -- byte code is, after all, a very >> compact representation of classes. And SHAP is specifically aimed at >> implementation in Field Programmable Gate Array (FPGA) boards; even the >> simplest of these has several times the memory envisioned by CLDC. >> >> George >> >> On Mon, Oct 17, 2011 at 5:07 AM, Kermit Kiser<[hidden email]> >> wrote: >>> René - >>> >>> How about opening an issue on Kenai for this one? >>> >>> Offhand it looks doable. In fact it might be possible to implement >>> Collection as well so that a Rexx object could be a collection itself as >>> well as a member of a collection. >>> >>> George - Does CLDC have collections stuff or would that require an >>> adapter? >>> >>> -- Kermit >>> >>> >>> On 10/17/2011 12:51 AM, rvjansen wrote: >>>> Let me float this thought for possible inclusion in 3.02: >>>> >>>> I use the Java Collection classes a lot. I have a class RexxComparator >>>> handy to make sure I can add Rexx objects to instances of Map (these need to >>>> be orderable, so Comparable). How about adding its methods and the interface >>>> signature for Comparable to the Rexx class? >>>> === >>>> /** >>>> * Class RexxComparator is a Comparator that gives us the possibility >>>> * to use Rexx Strings in Collection classes without encountering >>>> * exceptions when using Collections.sort(). It implements the compare >>>> * method of the Comparator interface. >>>> * @version $Id: RexxComparator.nrx,v 1.1 2009/06/18 15:50:30 ja3878 Exp >>>> $ >>>> */ >>>> class RexxComparator implements Comparator,Serializable >>>> >>>> properties constant >>>> serialVersionUID = long 991920429 >>>> >>>> method RexxComparator() >>>> super() >>>> >>>> /** >>>> * method compare returns a negative if the first argument is >>>> * smaller than the second, and a positive number when it is >>>> * bigger. >>>> * @param i1 the first String >>>> * @param i2 the second String >>>> * @return int -1 if i1< i2, +1 if i1> i2 >>>> */ >>>> method compare(i1=Object, i2=Object) returns int >>>> i = Rexx i1 >>>> j = Rexx i2 >>>> >>>> if i< j then return -1 >>>> if i> j then return +1 >>>> else return 0 >>>> === >>>> >>>> The Rexx class itself is already serializable, but lacks a long >>>> serialVersionID, and this leads to RMI exceptions whenever the language >>>> runtime is recompiled. To minimize these occurances, we could add it, and >>>> only change it when we really have updated the Rexx class. With infrequent >>>> updates, this is manageable, but if we are going to release more often it >>>> will be a burden on RMI users with deployed applications if we have this >>>> chance more than necessary. >>>> >>>> Let me know what you think. >>>> >>>> best regards, >>>> >>>> René Jansen >>>> >>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>> >>>> >>>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> >> >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > > > Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: implementing comparable & adding serialversion to Rexx (the class, not the language)
|
|
In reply to this post by Kermit Kiser
Kermit,
Re "Actually George, I was mainly thinking about whether or not adding
the interfaces "Collection" or "Comparable" to class Rexx would
cause a problem for CLDC, but the presence of some collections
classes sort of implies that the interfaces would be there right?" No. The classes and interface I listed are all there is. The Collection Interface was introduced in J2SE 1.2 (CLDC is based on J2SE 1.3.1), but Vector and Hashtable go back to 1.0. No attempt was made to fit these into the Collection framework, although a method was added to Hashtable to return a Collection. Instead, new Collection-friendly classes were added: Hashtable -> HashMap, Vector -> ArrayList. Stack extends Vector. Methods of Vector and Hashtable returning Enumeration date to J2SE 1.0.But do Collection or Comparable have to be present in SHAP/CLDC boot classes? AFAIK Shap's linker will load them via classpath if they aren't. Comparable appears inconsequential, but Collection more substantial. However, assuming I don't explicitly make use of collection classes, what is the actual impact, except for a (slight?) increase in class Rexx's size? I'm pretty sure SHAP's loader deletes unused methods. Or am I missing something? BTW, java.io.Serializable is absent from CLDC, and I wonder if this could be a zinger? Rather than make Rexx a Collection, would it be useful to give Rexx a method returning a Collection, as Sun did with Hashtable? I haven't looked at their code to see how they went about it. George On Mon, Oct 17, 2011 at 12:46 PM, Kermit Kiser <[hidden email]> wrote:
_______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: implementing comparable & adding serialversion to Rexx (the class, not the language)
|
|
In reply to this post by Kermit Kiser
Kermit,
I realize I don't know what it means for a Rexx object to be a Collection. George On Mon, Oct 17, 2011 at 2:12 PM, Kermit Kiser <[hidden email]> wrote: Thanks Rick. That was indeed what I was wondering based on the fact that the classes George listed were around in "pre-collections" days. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: implementing comparable & adding serialversion to Rexx (the class, not the language)
|
|
In reply to this post by George Hovey-2
George -
I don't really know anything about SHAP/CLDC. I can't answer your questions, but I do recommend that you run some tests to see what can and cannot be done. There is usually some way to make things work with the right approach. And there is a lot of experience and expertise on this list. BTW: A Rexx object contains a "Schrodinger's" Hashtable, meaning that it may or may not exist but any access to it will find it to be in some state. Thus it might be possible to return a Hashtable from a Rexx, which could then be converted to a collection. -- Kermit Kermit, _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by George Hovey-2
Hi George,
could you please comment shortly what is *your SHAP package* ? Thanks in advance, Thomas. ========================================================= Am 17.10.2011 17:42, schrieb George Hovey: Kermit, --
Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |