Was this a hidden X-Mas gift? Since when do we actually have support for Progress.Lang.Object columns in WORK-TABLES or WORKFILEs?
10.2B03 fixed this issue
OE00198911 | * | LANG OO4GL | Defining a work-table to hold objects of type PROGRESS.lang.OBJECT and then assigning a class object to the work-table field will hang or crash the Progress session in 10.2 | 10.2B03 |
So obviously at some point there must have been support and an issue with PLO in WT/WF that has been fixed now. And this code will actually work:
DEFINE WORK-TABLE wtTest
FIELD i AS INTEGER
FIELD o AS Progress.Lang.Object .
DEFINE WORKFILE wfTest
FIELD i AS INTEGER
FIELD o AS Progress.Lang.Object .
CREATE wtTest.
ASSIGN wtTest.i = 42
wtTest.o = NEW MyClass () .
CREATE wfTest.
ASSIGN wtTest.i = 42
wtTest.o = NEW MyClass () .
FIND FIRST wfTest .
MESSAGE wtTest.o:GetClass():TypeName
VIEW-AS ALERT-BOX.
Will this allow us for a more lightweight collection implementation than using temp-tables?
The initial implementation of the OO ABL supported Progress.Lang.Objects in work-tables. This capability broke when we introduced garbage collection. This regression was resolved by the issue you cited.
Cool!
Was this a hidden X-Mas gift? Since when do we actually have support for
Progress.Lang.Object columns in WORK-TABLES or WORKFILEs?
According to the bug, since at least 10.1A Also, I can't find any reference in the doc that says it doesn't work.
What you cannot do, though(from the help) is
" You cannot define a SHARED or NEW SHARED work table in a class definition (.cls) file. If you do, ABL generates a compilation error."
So if you want to create work-table-based collection classes, you'll need a level of indirection.
-- peter
" You cannot define a SHARED or NEW SHARED work table in a class definition (.cls) file. If you do, ABL generates a compilation error."
Great, away with that mess!
So if you want to create work-table-based collection classes, you'll need a level of indirection.
Sorry, Peter I can't follow you. Why do I need indirection? I don't plan to export the work table to anybody except by a Add() method and a GetItem() method.
Then I misunderstood you. I thought you wanted to say
Class collection:
Def work-table Data no-undo
Field objRef as P.L.Object.
Method Add().
Property Size as int.
End class.
That is what's not allowed, as I read the help.
-- peter
That is what's not allowed, as I read the help.
You're sample has no SHARED / NEW SHARED definitions. So I still don't get your objection.
I tried defining both a work table and a workfile in a class without any compiler issue. I'd never be that stupid to define anything SHARED in a class.
mikefe wrote:
That is what's not allowed, as I read the help.
You're sample has no SHARED / NEW SHARED definitions. So I still don't get your objection.
I tried defining both a work table and a workfile in a class without any compiler issue. I'd never be that stupid to define anything SHARED in a class.
My apologies for the noise; long day, brain full.
Of course there's no SHARED anywhere - I just skip-read right over that - and so of course what I said was nonsensical.
-- peter
>Of course there's no SHARED anywhere - I just skip-read right over that - and so of course what I said was nonsensical.
So we're free to eventually implement better collections now. What a day to celebrate
Makes me forget, what trouble ESD caused me today to download the list of the fixed issues.
mikefe wrote:
So we're free to eventually implement better collections now. What a day to celebrate
How will you deal with List-type - ie ordered - collections? Or will you use TEMP-TABLEs for those, and WORK-TABLES for the others?
-- peter
How will you deal with List-type - ie ordered - collections? Or will you use TEMP-TABLEs for those, and WORK-TABLES for the others?
Good question. Will first have to test work-tables first.
Then I'll have to think about how to support the one type of Lists in the SmartComponent Library for 10.2B03 + and the other one for 10.2B, 10.2B01 and 10.2B02 for people still on outdated releases. That was already fun enough with -IOEverywhere 1
Looks like I'll need a List factory taking the service pack level into account.
I reported the problem quite a while ago when I was early in my consideration of doing a second round on collections. The documentation, at least at the time, did not list PLO as one of the possible variable types in a WT and so my initial assumption had been that it was not possible to use them, but when I actually tested it, it was perfectly possible to define such use ... it just failed when one actually tried to use it.
It is not absolutely clear that WT will be a good solution for collections since it is known that the implementation of WT is not exactly a model of efficiency and minimalism. But, it certainly bears competitive testing if it is not possible to use them.
As for ordering, that depends on need. Collections which are ordered by the sequence of addition, the most common need, are obviously no problem. Collections which are ordered on object identity will require a work-table that has both an ID field and a PLO field and one will have to go through that funny process of searching sequentially for the last ID less than the new ID and making the addition with the pointer there in order to put the collection into order. For key ordered collections one would need a key field and a PLO and do the same thing. For the latter two, it is likely that performance will be pretty terrible with large collections, but it is certainly worth testing both performance and memory footprint compared with TT implementations to see if one can get good performance with a smaller memory footprint.
Definitely something to check out!!!!