OO Wish List - Forum - OpenEdge Development - Progress Community
 Forum

OO Wish List

  • Someone beat me to the first post in the new forum, but let me draw your attention to my OO Wish List at http://oehive.org/OOWishList

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Nice list. Three comments and two questions:

    4) It would be more useful if you prioritised the items.

    3) If you could have any 3 items on your list, but only 3, which ones would you choose, and why?

    2) Some of the items have nothing to do with oo4gl and should perhaps be on a separate list

    1) Some interesting languages to study are: Scheme, Dylan, Erlang, Lua, and Fortress.

    0) Why isn't closures on your list?

    -gus

  • 4) It would be more useful if you prioritised the items.

    Eventually, I might, but I was thinking to do that more by building business cases for each item that would convey its importance and then to combine that with its difficulty of implementation to give an overall sense of where it should come in the priority queue.

    3) If you could have any 3 items on your list, but only 3, which ones would you choose, and why?

    I'm sure this changes depending on what I am working on. E.g., I recently tried to apply a certain beta language feature to my previously published collection classes, expecting that it would help me make them simpler and easier to use, but then realized that the new feature was only a piece of what I needed and that I needed either generics or object versions of primitives in order to really do the kind of transformation I was hoping for. Consequently, right at the moment, those are two hot buttons.

    2) Some of the items have nothing to do with oo4gl and should perhaps be on a separate list

    Which do you mean? I think that there are some that might appear on more than one list, but they are on this list also because they relate to my OO development work.

    0) Why isn't closures on your list?

    Please post a comment to add it.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I'm sure this changes depending on what I am working

    on. E.g., I recently tried to apply a certain beta

    language feature to my previously published

    collection classes,

    Since you promoted the hive-site very well, I can see a reference in almost every forum, I took a brief look at your collection classes. I don't want to argue about implementation details, but due to the nature of the 4, ehh, ABL, you have implemented the collections via temp-tables. Deleting an item in the "virtual array" means renumbering the underlying temp-table. Performance is not the first priority when prototyping, but do you think this approach is feasible? I mean, you store object handles, when will these objects be disposed, since the ABL has no garbage collection?

    Due to problems (missing GC) like this I really question if OOABL is suitable for a model driven architecture: a data driven architecture, where temp-tables flow throw objects, seems like a more natural approach for the ABL. Don't get me wrong, with "more natural" I mean the target language the ABL, not my preference or the architect's preference.

    Back to your OO-wish list: when you want to say goodbye to temp-tables & datasets and you want to represent entities as class instances, I can understand your wish list. Perhaps a question to Gus: do you think this is the way to go... It would have been nice if we could have asked Mary, our dynamic temp-table, query & prodataset hero, as well

  • I don't want to argue about implementation details,

    Feedback is always welcome. That is why this is a .01 release. You will see lots of things in the doc that aren't addressed yet. Not to mention how much prettier one could make them with method overloading and either generics or class equivalents of primitives. I don't pretend that this is anything other than a first cut to get things moving.

    Deleting an item in the "virtual array" means renumbering the underlying temp-table.

    Only if you are merely keeping a sequential collection. Any time you are using a map, which I expect to be 99% of the cases, then no renumbering is required. I also think that in most cases the collection is the result of a query and one does something with it, but there is no significant amount of addition and creation of entries. Happens, of course, but mostly in sets that aren't very large.

    As to garbage collection, like anything else the cleanup has to be in the place where the object is created.

    I think you are going to have to explain your point about MDA ... I don't get it.

    I am very much oriented toward an OO4GL, not wanting to merely reinvent all the things that happen in an OO3GL. I see no reason to get rid of power.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I think you are going to have to explain your point

    about MDA ... I don't get it.

    There is the data centric architecture on one side. You define messages, documents, datasets, you name it on one side and a operations on the other side. You create the data structure and hand it over to a method (service) which processes the data. The service delegates it's work to other services, passing the data down the line. Basically this is the way we work with ABL (and it's a way to work in .Net using datasets). A 4GL temp-table is disconnected from it's behavior by default: you can change a value in a buffer without any logic guarding it.

    There is the domain model way of doing things on the other side: you have classes that expose properties and operations. Object relational mapping is popular in this arena, since persistence is considered to be just another aspect of the code. In this environment the "data transfer object" is used to cross network boundaries.

    As far as I have interpreted your forum messages, you want to create OOABL classes, that behave like the domain model. This means you will hide temp-tables and buffers and you will expose entity class instances instead. So for every order you will have an Order-instance that exposes attributes like "OrderId", "OrderDate". etc. It will also expose an orderlines collection. Now I'm wondering if the OOABL is suited to work like this...

  • I think you must be reading things into my posts that I am not aware of. To me, if one is working in an OO paradigm, then everything that is not directly interacting with the data source works in terms of objects. What is in that object and how it behaves is according to how one designs it, not how it is stored. Object relational mapping happens only at the interface and then only if the data source is a relational DB (it might be XML over the wire, for example).

    Now I'm wondering if the OOABL is suited to work like this...

    And, why not? I suppose that the existence of a wish list is an acknowledgement that I would like more complete OO support than I have so far, but that doesn't mean that one can't do real work. So far, I have run into places where I had to do a workaround, e.g., the one I did for singletons, and I have run into places where the implementation was less elegant than one might wish, e.g., collection classes, but not instances where one can't get the job done. I don't pretend to have everything figured out yet, but I'm working on it ...

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I think you must be reading things into my posts that

    I am not aware of. To me, if one is working in an OO

    paradigm, then everything that is not directly

    interacting with the data source works in terms of

    objects. What is in that object and how it behaves is

    according to how one designs it, not how it is

    stored.

    In theory this is all nice, but in reality it's much harder. When you reach the UI-tier, it's all data again you bind to. Sure, you can bind to plain .Net objects in .Net 2.0 nowadays, but for an ABL-widget it's not possible to bind to an OOABL-instance (as far as I can see). And once you're mixing ABL-logic with .Net UI, you will be marshalling datasets, so that's disconnected data as well (disconnected from business logic

  • [i[for an ABL-widget it's not possible to bind to an OOABL-instance

    Well, I'm not sure what you are saying here. If the UI is being presented by an ABL client, then the UI is defined within a class for that purpose. If the UI is being presented by something else, then there is an interface to the something else and the nature of that interface will depend on the something else. I'm not sure what you are trying to bind to what and not succeeding ( unsuccessful bondage? ).

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • ( unsuccessful bondage? ).

    I give up... and I go back to the C# world I have been working in for the last couple of years. Bye, bye!

  • Don't leave ... I'm sure that you have a point which is clear to you, it just isn't clear to me.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Don't leave ... I'm sure that you have a point which

    is clear to you, it just isn't clear to me.

    Yes. Please come back when you can anytime. We really need more experienced and thoughtful OO people to share their views here with the community, not less.

    Phil

  • [i[for an ABL-widget it's not possible to bind to an

    OOABL-instance

    Well, I'm not sure what you are saying here. If the

    UI is being presented by an ABL client, then the UI

    is defined within a class for that purpose. If the

    UI is being presented by something else, then there

    is an interface to the something else and the nature

    of that interface will depend on the something else.

    I'm not sure what you are trying to bind to what and

    not succeeding ( unsuccessful bondage? ).

    I'm thinking he's saying that when using non-ABL UI's, ther'es no OOABL objects to "attach to" and have the UI to interact with - it's all data being marshalled across the wire.

    Effectively, you'll need to either duplicate the OO BL on the other side, or have lots of chat between the UI and the backend as the user does their thing.

  • I'm thinking he's saying that when using non-ABL UI's, ther'es no OOABL objects to "attach to" and have the UI to interact with - it's all data being marshalled across the wire.

    While three is certainly an issue about what can be sent across the wire, the specifc piece I was responding to was for an ABL-widget it's not possible to bind to an OOABL-instance. To me, that sounds like a ABL widget, presumably in the context of an ABL session, and an ABL domain object instance ... i.e., no non-ABL components involveds.

    It seems to me that we have several possible variations here and I'm not sure what the issue is that is being raised.

    If we have an all ABL solution, then the ABL widgets are within a class, but one would expect this class to be distinct from the domain class per MVC principles.

    If there is a non-ABL UI, then obviously those UI widgets can't bind directly to the ABL domain object, but then one wouldn't want them to per MVC principles. One could send the UI object a copy of the data in the form of a PDS ... and that certainly wouldn't have all of the BL associated with the domain object, but I thought we agreed that this separation is what one should do per MVC principles.

    See http://www.psdn.com/library/thread.jspa?threadID=2211&tstart=0 for a discussion of MVC, including both the basic version and the higher level of separation which I was advocating there.

    I.e., OK so either one can or one can't bind the widget to the domain object, but why is this a problem since one shouldn't.

    Effectively, you'll need to either duplicate the OO BL on the other side, or have lots of chat between the UI and the backend as the user does their thing.

    Some BL probably does belong in the UI, e.g., stuff at the level of "this field must contain a valid integer". I don't see how one can completely avoid this without either violating MVC or having a really annoying and deadly slow interface. But, the "interesting" parts of the BL don't belong in the UI. Some of them require interaction with other domain objects and some possibly can't be really validated without reference to the database. One certainly doesn't want that in the UI! So, one strikes a balance between insuring that one has a superficially valid set of data at the UI level and relying on the back end as to whether this is completely acceptable or not.

    A simple classic example is multiple order entry sessions which obtain information that a limited number of a certain item are still available. But, both sessions are working independently and neither has committed its work. Then, one session commits and now those items are no longer available. If we had inter-session pub-sub, one could imagine the domain object signalling the second session of the need of a refresh, but even then there is a certain risk of the second session attempting to commit and only then it is discovered that the basis on which that commit seemed reasonable was stale and the commit must be rejected.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • To me, if one is working in an OO

    paradigm, then everything that is not directly

    interacting with the data source works in terms of

    objects. What is in that object and how it behaves is

    according to how one designs it, not how it is

    stored. Object relational mapping happens only at

    the interface and then only if the data source is a

    relational DB (it might be XML over the wire, for

    example).

    There are a number of interesting and different points being discussed in this thread, but let me try to put in a thought on one or two of them. One is that, at the risk of being simplistic, one of the benefits of the class-based extensions to ABL that we have been striving for is to let you be "as OO as you wanna be". You don't need to be having a spritual object-oriented experience to be taking advantage of at least some of the benefits. As Thomas has been pointing out in several of his posts, in one way or another, a lot of the mundane issues are there whether you're trying to express things in object-oriented terms or not, like what parts of the BL can reasonably be executed on the client and what you do about it, or how you bind data values to the UI in reasonable ways.

    The specific point I quoted above is a key one, though, and one where there is ample room for debate. If I understand the point, I think I disagree about everything above the data source level being in terms of objects. I think one of the continuing benefits of working in ABL is that you can treat data in a fairly object-oriented way where you really want to, but you're not forced to. If you want to encapsulate the (originally relational) data very tightly in objects, you can certainly do that, but there are many times when it's still greatly advantageous to use good old FOR EACH loops and direct field references and so on in your logic, and as long as you control at an appropriate level who has access to the bare tables and DataSets in that direct manner, then you should be able to provide the level of control that is part of the OO paradigm. So I can provide limited or no direct access to my temp-tables etc. from outside a business entity (to use that as an example), but within the b.e. (and away from the data source) it can still be a great advantage to express business logic in the same way as we have always done, which is definitely relational -- fully OO languages don't really enable that. It's true that I can't pass an object across the wire yet in ABL, but then, given the percentage of the BL that represents the supporting logic for that object that I can't execute on the client anyway, that isn't necessarily a hindrance. I can encapsulate a relational DataSet in an object on the server-side, and then pass just the data across the wire to a separate object on the client side with very different responsibilities.

    In general, you can take advantage of various benefits of the class-based language, including strong typing and some measure of inheritance and so on, and not be very truly object-oriented at all. Or you can be much more thorough in how much you treat things as objects and not just as code expressed as classes and methods. It's up to you; lots of rope to hang yourself with, of course, so could development models and guides are needed, but the flexibility is there.