I'd like to turn around an earlier thread on this forum to ask the question, "Given that one is running 10.1A or greater", is there any reason not to be implementing new features using OO?"
Obviously, there are cases in which the change to be made is trivial in relationship to the existing code base and it is not economic to change the whole paradigm just to make those small changes. Similarly, there are cases where the change, while not itself that trivial, is embedded in a very complex set of routines that might require significant rework to include even a small component of OO and no manager is likely to authorize such a thing. Likewise where the change is to something used many places in the application so that changing the way it is invoked would require a lot of work.
But, what about those times when one is adding new functions or making major rewrites or where the disruption to existing code is trivial because the new work is well encapsulated? Are there reasons not to use OO for these cases, given the advantages cited for OO? Isn't this at least a small step in the direction of a larger modernization?
I ask this because here we are something like a year and a half since PSC insiders and beta testers could start working with OOABL, but even the newest publications are still firmly in the .p camp. OK, in some cases I can see wanting to illustrate both .cls and .p approaches when the techniques are applicable in both places, but shouldn't we be seeing at least some OO examples because this is the best way to do things in the current versions of ABL? Or doesn't PSC believe that?
Mind share would be a big one - it takes a different way of thinking to get your head around OO development when coming from non-OO structures, even if the procedures have been highly structured in the past.
The question will be: when do you stop OO-ing that piece of logic? When lots of man years have been spent on procedural code, what will bring a couple OO-classes? I think a lot of applications are struggling already with modernizing their (G)UI.
Another "why not": the ABL is a data driven language, where temp-tables and prodatasets fly around. Once the ABL goes the route of brokering "entities", making it easy again to deal with database access, we have a different story. Right now I see architectural examples that deal with buffer handles, object handles, etc...
Probably the simple answer is that it takes time for things to catch on.
It's my feeling that SOA/OERA, datasets etc. are only now slowly starting to sink in to the developer community. If they made all the samples in OO they would be making them especially for you, well, not exactly but not alot of people would be able to participate right now.
You have to give it time. Maybe 5 years from now OO will be widely adopted but because this is Progress it will probably take that much until most developers even have access to a version with some level of OO support so realistically twice that much or it'll never really happen
OK, but in the transition to 7
we had the move from procedural thinking to event-driven thinking,
which required putting on a new mindset, but I didn't see people
arguing that one should not do event-driven just because it wasn't
what one was used to. That's what I'm asking here ... it seems to
me that OO is better, so is there any reason it shouldn't be the
recommended approach in the same way that event-driven was.
Obviously, a couple of classes
isn't going to transform the application, but it is a start. E.g.,
a number of years ago I found myself with a legacy application
using a ton of shared variables for context. There was no funding
to re-write the whole thing in one swoop, but that didn't keep me
from creating a superprocedure alternative and then starting to use
that alternative in any new code or any major revisions. It didn't
fix the whole application, but at least it created islands of
"beauty".
And this need to have
matching temp-table definitions all over the place is one of the
advantages of using objects instead.
It's my feeling that SOA/OERA, datasets etc. are only now slowly
starting to sink in to the developer community. If they made all
the samples in OO they would be making them especially for you,
well, not exactly but not alot of people would be able to
participate right now. At the partner summit it was said that in 2006: * OE10
had a 200% growth in seats; * OE10 had a 160% growth in sites; *
OE10 has over 10,000 sites; and * more than 50% of partners are
deploying on OE10. Now, that doesn't mean 10.1A or B, but if they
are on any OE10 release, there isn't much of a barrier to being
fully current.
Thomas,
Starting on the OO path with a major existing application would be much easier if you could:
- inherit from built-ins
- get a handle to an object
That would make the new objects fit in much better with existing approaches.
Lucas
Starting on the OO path with a major existing
application would be much easier if you could:
>
- get a handle to an object
Isn't there a "THIS-OBJECT" handle?
If by "inherit from built-ins" you mean being able to subclass existing controls and the like, I'm afraid that the time to have made that decision was in the design of V7 and it is now unlikely to ever happen now. We might see object-like additions to pseudo-objects like PDS, but that's all I expect.
What is it that you think you could do with this ... other than the impossible, like subclassing a browse to modify its behavior? At the .p level, it is pretty straightforward to just turn a .p into a .cls in most cases.
What is it that you don't have in terms of handles to objects and what do you want to do with it?