FIND + methods call

[DevTeam]

This is just a warning, for those who do not want to spend time wondering why their program does not work...

In ABL, things like that :

FIND myTable
WHERE myTable.Field1 = getProperty1()
AND myTable.Field2 = getProperty2()
AND myTable.Field3 = getProperty3()
AND myTable.Field4 = getProperty4().

fail as the methods values seem to be resolved AFTER the "=" test..........

 

[tamhas]

Is this internal to the object?

Have you tried using properties?

Have you reported it to tech support?

 

[DevTeam]

Is this internal to the object?

Have you tried using properties?

Have you reported it to tech support?

Hi,

Yes, the getters & setters are internal to the object... In fact, they are declared into an "abstract" table from which the actual class inherits...

I chose not to use properties as I keep in mind the aim of creating grammar rules in order to translate - more or less - easy ABL routines into Java programs... So I prefer to use "classical" Java conventions... In addition of that, I do not know if it is possible to add routines into "automatic" GET & SET of properties, whereas I can do lot of things into classic getters & setters.

And no, I did not report it to Progress support as I just discovered it and I would like to be sure before bothering them... And as I am in vacation tonight, for 3 weeks.......

 

[tamhas]

So, in programming OOABL you are going to refrain from using temp-tables and other higher-level constructs because there is no parallel in Java?

Yes, you can override the get or set side of properties or both, so it is very, very easy to create read only or write only properties and very simple to write and use properties when no logic is required. WAY SHORTER!

I guess it also seems to me to be overly indirect to use a getter method to obtain the value of a data member for use in a FIND when one is inside the class where the data member resides. The only possible justification I can think for doing so is if the value is a compound of some sort and so logic is required to create it.

I haven't tried testing this myself, but I presume that you have tried assigning the value of the getter methods to a local variable before doing the FIND just to make sure that the problem is what you think it is and not some other issue?

 

[DevTeam]

So, in programming OOABL you are going to refrain from using temp-tables and other higher-level constructs because there is no parallel in Java?

About Temp-Tables, a memory database, such as H2, could be used in order to reproduce TT fast access. I managed to recreate a mechanism corresponding to shared variables... And for the moment, I am not stucked with a syntax without matching in Java...

Yes, you can override the get or set side of properties or both, so it is very, very easy to create read only or write only properties and very simple to write and use properties when no logic is required. WAY SHORTER!

Good to know ! Especially if that's faster !

so logic is required to create it.

You guessed !

I haven't tried testing this myself, but I presume that you have tried assigning the value of the getter methods to a local variable before doing the FIND just to make sure that the problem is what you think it is and not some other issue?

Exactly. The only way the "FIND FIRST" worked was when I did not specify a condition...

In fact, I also got a clue when Architect refused to compile my code because of a type mismatch between a date-type field and one of the getters, supposed to retrieve a date too......

 

[lord_icon]

Re: FIND ???? ABL ???

Greetings,When using ABL why are you using FIND? The ABL approach would be to create and use a query. DEFINE queryName WHERE ... THEN simply openQuery queryNameThat is far more efficient AND ABL

 

[tamhas]

About Temp-Tables, a memory database, such as H2, could be used in order to reproduce TT fast access.

The point is not "can you imitate this in Java?" but, what is the best way to utilize OOABL? I.e., learn from standard OO best practices, but just the same way that one does things a bit differently in Java, C#, and C++, so should you do them differently in OOABL. Otherwise, you are just doing a sort of worst-case line-by-line translation and that isn't going to give you good code.

I managed to recreate a mechanism corresponding to shared variables...

Where is the smiley? Surely you aren't serious about wanting to imitate one of ABL's most unfortunate residual features? Do you write your Java code with public data members too?

And for the moment, I am not stucked with a syntax without matching in Java...

Stuck? How stuck? Seems like what you have going here is a way to write ugly ABL *and* ugly Java. This is not a virtue.

Exactly. The only way the "FIND FIRST" worked was when I did not specify a condition...

No, what I was suggesting as a test to make sure you are seeing what you are thinking you are seeing is to define a local variable for the return value of each of the get methods, assign the local variable using the method, *then* use the local variables in the FIND and, presumably, also display them so that you see what you actually have. I am not recommending this as best programming practice, but rather just as a diagnostic to make sure the problem you think you are seeing is actually the problem and not something else.

In fact, I also got a clue when Architect refused to compile my code because of a type mismatch between a date-type field and one of the getters, supposed to retrieve a date too......

Which is a clue that something isn't as you think it is ... not a clue that there is some kind of deferred execution going on.