prodataset using temp-tables in classes

Posted by jmls on 15-Mar-2012 06:12

I'm trying to create a dataset in a class, using temp-tables in other classes without having to share or duplicate anything

let's say I have the following

class a:

def temp-table TTA no-undo

     field ID as char

     field Name as char.

class b:

def temp-table TTB no-undo

     field ID as char

     field c as char

     field d as char.

I now want to create a third class (c) that has a dataset, but uses the temp-tables from class a and b.

is this possible ? Or would it simply be better to combine both classes into class C

All Replies

Posted by WJCPvanBeek on 15-Mar-2012 08:10

Hi Julian,

There are several ways to accomplish this. Below is the dynamic way.

class a:

def temp-table TTA no-undo

field ID as char

field Name as char.

define public property handle as handle no-undo

get():

return temp-table TTA:default-buffer-handle.

end get.

end class.

class b:

def temp-table TTB no-undo

field ID as char

field c as char

field d as char.

define public property handle as handle no-undo

get():

return temp-table TTB:default-buffer-handle.

end get.

end class.

class c:

define private variable a as class a no-undo.

define private variable b as class b no-undo.

define private variable ds as handle no-undo.

constructor c():

a = new a().

b = new b().

create dataset ds.

ds:set-buffers(a:handle,b:handle).

end constructor.

end class.

The dataset in class c now directly uses the temp-tables from class a and b.

However, you can only acccess the data in the temp-table dynamically.

I'll soon send you a sample of how to do this statically.

Best regards,

Will

Posted by WJCPvanBeek on 15-Mar-2012 08:30

Attached are the files to statically use the temp-tables in class a and b.

class a and b own their temp-table. Class c has access to them to read or write data. It's important to note that class c uses the temp-tables of class a and b; it does not have a separate instance of these temp-tables. That's because of the reference-only keyword, which means that the temp-table definitions in class c are only for reference by the compiler. At runtime these temp-tables do not exist, and class c can only 'hire'them from a class that owns them.

Hope this helps,

Regards,

Will

Posted by Admin on 15-Mar-2012 08:31

I'm trying to create a dataset in a class, using temp-tables in other classes without having to share or duplicate anything

Do you want to share the data, the definition or both?

Share the definition: Include files (I know, you're gonna love this)

Share the data: dynamic access using handles

Share the data and definition: Check for BIND on the parameters - but be aware that there is no unbind.

Posted by jmls on 15-Mar-2012 08:37

yeah, that's what I was missing - the "reference" and "bind".

I'm not worried about the include files, as these classes are automatically generated by Maia, so the "static" definition will always be up to date in all three classes.

thanks again

Posted by WJCPvanBeek on 15-Mar-2012 09:20

glad to be of help.

Attached is a powerpoint slide that explains all the variations of passing temp-tables/dataset.

regards,

Will

Posted by AdrianJones on 15-Mar-2012 11:12

Very cool slide. thanks for posting!

Posted by Thomas Mercer-Hursh on 15-Mar-2012 11:45

I vote for combining them all in class C.  Passing handles of TTs between classes is an egregious example of bleeding cohesion and failure to encapsulate.  If the TTs are part of one dataset, then they are part of one subject matter, i.e, in one class.

When something gets tricky to pull off, it is a hint that maybe you shouldn't be doing it!

Posted by Tim Kuehn on 15-Mar-2012 11:46

Make the TT's "protected", and then inherit them in the target subclass and use them as if they were instantiated locally.

This assumes, of course, that class "a" and "b" are both part of that inheritance chain.

Posted by Thomas Mercer-Hursh on 15-Mar-2012 12:00

Julian will have to comment, but I see nothing in what has been said so far to suggest that inheritance was involved.  In some languages, not ABL, one could inherit from multiple parents and consider forming the dataset in the child with parents a and b, but ABL doesn't have multiple inheritance, thankfully.

Posted by jmls on 15-Mar-2012 12:15

class a and class b have no class relation to each other , and operate independatly on temp-table data

however, I also need a class c to group a and b together into a single dataset

Posted by Thomas Mercer-Hursh on 15-Mar-2012 12:32

Then I think you need to answer this question:  Are the two TTs sufficiently independent that I should encapsulate each separately and do my data-set-like operations on them from outside or are they interdependent and inherently part of the same dataset and I should put them in the same class.  Trying to both is persisting relational thinking into the object model.

Posted by Admin on 15-Mar-2012 14:10

tamhas wrote:

Then I think you need to answer this question:  Are the two TTs sufficiently independent that I should encapsulate each separately and do my data-set-like operations on them from outside or are they interdependent and inherently part of the same dataset and I should put them in the same class.  Trying to both is persisting relational thinking into the object model.

indeed, just because you can doesn't mean you should ... http://www.demotivation.us/perception-1246850.html

and as a side note, you do know that one table can't be part of more than one dataset at the time... just in case a new D object might be tempted to use one of those

Posted by Thomas Mercer-Hursh on 15-Mar-2012 14:25

A very good reason *not* to encapsulate the TTs separately since there is nothing in the class to tell you that you can't do that.

This thread is closed