Hello,
does anyone know if Generics are officially planned for OE11.0?
Thanks,
Jan
does anyone know if Generics are officially planned for OE11.0?
I don't know the answer to your question.
But right now we use include files in a class as a workaround to the lack of Generics.
CLASS ListOfTypeX:
{ Consultingwerk\List.i TypeX}
END CLASS .
In the include file we implement the required methods and properties using the include file parameter whenever we need the variable type.
Works for us as typically we only need a limited amount of generic types in an application.
It's a nice suggestion, but that's probably just a workaround within ABL, the reason I 'need' generics is I would like to use a .NET assembly who's API uses generics. I think I need to write a wrapper in .NET that hides the generics for using this API in 10.2B.
It's a nice suggestion, but that's probably just a workaround within ABL, the reason I 'need' generics is I would like to use a .NET assembly who's API uses generics. I think I need to write a wrapper in .NET that hides the generics for using this API in 10.2B.
You can define .NET generics from the ABL since 10.2B. You should be able to define a generic type with T being a .NET Interface and an ABL class implementing that interface as the members.
Does that help? Or do you need an ABL generic class? For achieving .NET visibility of that type you'll need a class inheriting System.Object anyway.
It might, I didn't know that, I'll have to try.
In 10.2B you can 1) implement a .NET interface that uses Generics and 2) instantiate a .NET Generic type using a .NET type for the Generic. For example List could be defined in ABL as List. You can run methods on the instantiated class since the Generics part of it is resolved by the definition.
What you cannot do is run a method that is explicitly defined as taking its own type (separate from its containing type). At this time this capability is not being considered for 11.0.
-Shelley
Crushing my hopes yet again ... even though, of course, it wasn't really news.
At the NorCal PUG meeting last week someone suggested that the motivation PSC had for supporting OO was entirely based on their interest in ABL GUI for .NET, which is certainly more natural in OO and there are some features which really only map on to OO constructs. I'm not that cynical, but there certainly are places where one feels that support for AG4.N has an overly dominant role in deciding which missing parts to implement next. I'm very grateful for the many extensions to the OO support that have been added since 10.1A ... there is a whole lot of my original wish list that has been added to the product ... but I also have to say that it is time for another big chunk and a chunk which has to do more with establishing parity between OOABL and other mature OO languages. I'm tired of having to make apologies and explanations and spins. Generics ... as dangerous and misused as they can be in much code are really very important for creating frameworks. How can we expect OO to get serious in the ABL world if we leave barriers to good frameworks?
Support for .NET generics, as Mike says, is there ... what we don't have is ABL generics. As Mike says, you can "fake" the ABL side ... where "fake" means avoid the stupid duplication of nearly identical ABL code differing only in type. You can see this illustrated also in my old collection and map class code at http://www.oehive.org/CollectionClasses . But, gosh it is ugly.
Thanks Shelley, now that I see the syntax I remember testing this in the past, I must have somehow forgotten it.
I'm relatively new to the Progress/OpenEdge scene, but I am very glad that Progress corp. at least added some support for object orientation in OpenEdge. It's probably what kept me from jumping off of a tall building after getting this job straight out of university.
That said, I don't think OpenEdge will ever get to be as serious/competent with OO as other languages currently are. There's just too much legacy baggage/backwards compatibility required for a language that was designed to be a top-down procedural language from the start. The other languages have the advantage of being designed as OO from the get-go. Progress/4GLs were an interesting idea in the 80's/early 90's, but let's face it - the 4GL concept lost out to better ideas (i.e. OO).
The snail's pace that a product like OpenEdge takes in small, incremental improvements (i.e. copying what other products have already had for quite some time) is not nearly fast enough anymore. Try comparing the latest OpenEdge to a modern solution like Ruby + MongoDB (a document-oriented, schema-less database). It's like comparing a horse and buggy to a Bugatti Veyron. These agile programming languages are the real 4GLs, so it is nice that Progress took that tag off of their programming language name.
The only solution I see is to completely migrate to a newer language and platform. Otherwise, you will be waiting until OpenEdge 14 for a solid OO platform (except it will probably not be "OpenEdge" anymore, it will have been renamed a couple times by then). And by that time, OO will be old news (well, at least the Java clone that Progress will surely have created, that is). If you wait around to migrate, you risk Progress corp. getting wise to the concept and really locking down the platform, like removing or deprecating JDBC drivers. Oh wait... didn't that already happen?
You might enjoy reading this
I actually already have several weeks ago; read the comments section. Might I counter with this (did I say Java was the solution)? Ignoring the fact that the article is a total puff piece, I do agree with the shill's author's general sentiment that Java is not the perfect solution and is probably overused in industry.
However, if I had to choose only one language to use and it was strictly between Java and OpenEdge, I would take Java any day. It has a real language specification, actual primitive datatypes, better OO support (including garbage collection from the start), portable code (import statement isn't brittle like USING is), not tightly coupled to a single (shoddy) datastore, interacts with other JVM languages at the bytecode layer (JRuby, Groovy, Scala...), widely used means tons of libraries available (including basics like Collections), and on and on and on...
The bottom line is just getting away from OpenEdge and getting onto any modern platform with an open spec is the ideal solution, because you will no longer be stuck in the single-solution, vendor lock-in that is OpenEdge.
If you don't want to work in OpenEdge .... don't. But, don't bother trying to convince us that are perfectly happy working in OpeneEdge that we are wrong to want to do so. Just no point. So, let us get on with arguing in favor of making it better. It does keep getting better, you know, significant so. How many of the databases you would like us to use support transparent data encyption ... and do so with anything like the efficiency OpenEdge does. How many have or plan to release multi-tenancy next year? How many include products like Savvion, Sonic, Apama, etc., etc. in their product mix ... with cmmon IDE too! OpenEdge is for real, serious applications, not toys.
tamhas wrote:
How many have or plan to release multi-tenancy next year? How many include products like Savvion, Sonic, Apama, etc., etc. in their product mix ... with cmmon IDE too! OpenEdge is for real, serious applications, not toys.
Sorry Thomas, but aren't Savvion, Sonic and Apama products that were available for Java before they were avaialble for OE? The IDE is also just Eclipse with some OE ABL tools added to them and if you've ever coded java in eclipse you will be aware that the java tools for eclipse are significantly better than the ABL tools. I also think the need for multitenancy in SQL databases is not even close to that in progress, because at least in MySQL you can just CREATE DATABASE... ; and upload the schema and all without much effort...
If you want to boost about OE strengths there's one very big one:
We've got over 7.000.000 lines of custom code, some of it is 18 years old, some of it is brand new. We've had to rewrite almost no code in all these years just because of an upgrade. If something works it just keeps working, yet when writing new code or even making changes/improvements to existing code we can use all the new possibility's we want.
I really would like the ABL to keep up with other languages progress (far far better OO and tools support, opensource libraries available, the ability to change schema online while everyone continues to work (that requires some care off course not to break applications but is often possible with SQL),...) but I would not want to have to rewrite all my code every five years to do so. While most Java code hasn't needed rewriting when new versions came about (like some other unnamed languages ;-)), but it hasn't been around for 18 years either and JRuby certainly hasn't been.
Trust me, I don't plan on working in it forever; I'm currently geographically restricted. However, my wife is deciding on a medical school right now and then we're outta here. Should be less than 6 months left now.
You're right that this probably isn't the place to open this can of worms. I just think that it is interesting that OE continues to push towards the cloud (e.g. that multitenancy you mentioned) instead of making the base language more dynamic. I guess it piqued my rage for reasons I won't expound upon for fear of prolonging the discussion.
If you're happy to work in OE... then by all means continue. I'll just post a link to the Ruby DataMapper adapter I'm writing when I finish it, for those who are interested. I know my employer is.
I really would like the ABL to keep up with other languages progress (far far
better OO and tools support,
I think that there's been demonstrated progress from Progress over the past few releases to improving the language wrt OO functionality (cf. abstracts, named events, etc). And certainly Java wasn't released fully-baked with all the features/functionality it has now.
>
opensource libraries available,
>
Opensource libs don't necessarily need to be created by PSC - if you/your company/your friends & relatives/your children have some code you're willing and able to share, there are plenty of places to host that - Google Code, Sourceforge and Github spring to mind immediately (and OE Hive too, although I don't know whether that has SVN repositories available). As my other favourite opensource project (MythTv) developers say (paraphrased): if you want to do something, do it yourself, 'cos no-one else will. (aka the "scratch your own itch" principle). There are plenty of such libraries out there too - for emailing and for WebSpeed and utilities and collections and a variety of other things.
Are you looking for/advocating/desiring a higher-level grouping of ABL opensource projects? Something like an Apache equivalent? Or just Some Damn Code?
-- peter
I'm not saying there is no progress or that ABL is a poor language, I'm only saying I would not be sad to see a couple of new features added a bit faster, that's a big difference ;-)
I'm only saying I would not be sad to see a couple of new features added a bit faster,
that's a big difference
You and me both. But that's the nature of developers, I think
(I wasn't taking your email as a knock on Progress, and I'm genuinely interested in what your thoughts on opensource libraries are).
-- peter
Multi-tenancy is an issue for the application and deployment, not whether the database is SQL or not. It is very easy to create a new OpenEdge database instance too, but that doesn't mean that one DB each is the optimum SaaS solution.
So what if some of those products were written in Java. The OpenEdge database server isn't written in ABL either. But, they are now all products of PSC.
Upward compatability is a PSC strong point, although the downside is that we now have a lot of people running systems with 25+ year old architectures.
Not only does OE Hive have svn, but it has the OERA Open Source Initiative http://www.oehive.org/OERAOSI
I've written a few. From my experience, OpenEdge is too weak of a language to ever attain the massive amount of reusable libraries that other languages have. I constantly seem to hit a roadblock that I either have to spend a lot of time dancing around (and trashing my design in the process) or am just stopped dead in my tracks because it isn't plausible. In other words, it's a language impetus, not a programmer one.
That's very true - Java has improved incrementally, for instance with generics not being accepted into the specification until 2004. Core features like garbage collection, however, were there from the get-go.
However, I think you're glossing over the finer points of the differing contexts between Java and OpenEdge in this regard. The Java language is an open specification; you or I could read the spec and write a compiler for the language (cf. the several popular ones out there - javac, GCJ, and ECJ; all open source). In other words, there is no reason to wait for the JCP members to approve a new feature into the language specification before upgrading the compiler to support said new feature; the compilers can lead the way. Contrast this with OpenEdge. One must submit an idea to Progress Corp. for approval, then wait for it to be approved (or denied), then continue to wait for it to be implemented into the only compiler available - Progress Corp's official one. It can be a quite a long process, and not always transparent along the way (e.g. announcing the status on a feature request in a reply to a forum post).
On top of that, think for a second about incentives. What does the JCP have to gain from delaying popular changes to the Java specification? Nothing. In fact, if they became stagnant they risk splintering the Java specification into competing versions, which could do great harm to the overall language if a clear winner didn't arise from it.
Now, what does Progress Corp. have to gain by delaying new features? Quite a lot. Remember this is a closed-source, licensed product we're talking about here, so monetary incentives are in play. So if they delay a feature until version n+1, users will want/need to buy version n+1 to get said feature. If they release a slew of requested features with version n and there's not a whole lot to do in version n+1, users will not see a reason to upgrade. Now this model could be a problem if users had a choice to migrate to a new platform, but let's face it - there's really no easy way for users to leave the OpenEdge platform. It could also be a problem for wooing new users to the platform, but obviously there isn't a big OpenEdge adoption rate. Most users are companies that have mountains of legacy code and are stuck with it.
Just sayin'.
>> So if they delay a feature until version n1, users will want/need to buy version n1 to get said feature. If they release a slew of requested features with version n and there's not a whole lot to do in version n+1, users will not see a reason to upgrade<<
What utter drivel.
Bzzt, Upgrades to version n+1 are free if you are on current
maintenance .... so there is absolutely no basis for what you are
trying to insinuate in that sentence.
Julian
Way too conspiracy theory. Let's turn this on its head. If someone has a idea for improving Java, they have to convince a committee of people from all over the place that it is the right thing to do, probably going through many interations of proposal and alternatives before some kind of consensus arrives. Conversely, PSC can decide to do whatever they want to do and just put it in the next release. They had better pay some attention to what we want or they are going to have unhappy customers, but they don't need our approval in order to act.
The big difference in the end is resources. PSC doesn't delay new features just to string things out. That is silly. They pick what they think is most important and what they can get done with the resources at hand by the time of the next release. There certainly have been cases of delaying something because they aren't yet sure what exactly they want to do ... e.g., what RIA technology to support ... but what do you want them to do if they aren't sure what is right?
What utter drivel.
>
Bzzt, Upgrades to version n+1 are free if you are on current
maintenance .... so there is absolutely no basis for what you are
trying to insinuate in that sentence.
Well said.
Does this include whole number upgrades, for instance 10->11? In that case I would retract my second statement. I honestly am not too familiar with the precise licensing terms since I am just a developer. I can only speculate (using a brain that has been corrupted by hatred for Progress).
OO - is just a tool, nothing more.
I used to write code on 4GL/ABL w/o OO and i see no real reason to change my programming style.
ABL has a great temp-table support. Temp-tables are suitable to keep and process objects. And do it faster when processing 1000-1000000 objects, a lot faster.
And there are no memory issues.
I saw dead OO projects, just because programmers focus on classes (a tactical tool) and forget about architecture/speed and real project goal.
Maxim
Yes, it includes everything. In fact, if you are still running version 2 and have been paying maintenance, you could update to version 11 next year without charge.
Occasionally, there have been licensing issues, but those have to deal with changing the basis of licensing not whether there is a version change. E.g., people with old machine-based license with unlimited users have had to do *something* when moving to a version that has only declared user counts and user based, not machine based licensing, but that has just been changing the form of the license and they have gotten full credit for what they paid for the original license.
Hungry sales reps make mistakes in license policy, but the policy itself is not predatory.
Actually, I would have to say "just a tool" suggests not really having done much to understand what OO is all about. The language features are only the tip of the iceberg. Good OO is all about how you think about decomposing the application and how the pieces act among each other. It is actually a philosphy of how to program. To be sure, one can write bad code in any paradigm and many principles that have fancy formal names in OO best practice are actually pretty good idea in traditional ABL as well, though some are harder to realize without the OO structures. And, yes, temp-tables and PDS have a role in OO. No one is asking you to not use something ... other than those things which are not best practice in traditional ABL either.
tamhas wrote:
Actually, I would have to say "just a tool" suggests not really having done much to understand what OO is all about. The language features are only the tip of the iceberg. Good OO is all about how you think about decomposing the application and how the pieces act among each other. It is actually a philosphy of how to program. To be sure, one can write bad code in any paradigm and many principles that have fancy formal names in OO best practice are actually pretty good idea in traditional ABL as well, though some are harder to realize without the OO structures. And, yes, temp-tables and PDS have a role in OO. No one is asking you to not use something ... other than those things which are not best practice in traditional ABL either.
Nailed it. If you don't see any reason at all to change (or at least supplement) programming style then you either straight up don't get OO or you are so overwhelmed with legacy code that you can't make it work for you. The elegant, reusable code it produces is a true thing of beauty.
I would maybe challenge you to write some code in a language other than OpenEdge that implements OO. Ruby, Java, C++, SmallTalk, whatever. It might make more sense with a clean implementation. Once you get a firm grasp on the basics, check out some GoF design patterns. Once you grok it, you won't go back.
It's kind of funny that we are even debating the merits of OO in the year 2010. It kind of saddens me.
tamhas wrote:
Yes, it includes everything. In fact, if you are still running version 2 and have been paying maintenance, you could update to version 11 next year without charge.
Occasionally, there have been licensing issues, but those have to deal with changing the basis of licensing not whether there is a version change. E.g., people with old machine-based license with unlimited users have had to do *something* when moving to a version that has only declared user counts and user based, not machine based licensing, but that has just been changing the form of the license and they have gotten full credit for what they paid for the original license.
Hungry sales reps make mistakes in license policy, but the policy itself is not predatory.
Well in that case I fully retract my second statement which was incorrect due to my own ignorance. Sorry about that. I'll try to tone down my rage-meter a little bit.
Thanks for filling me in.
Check out my website in a couple of days for a presentation on OO best practice. And, yeah, I'm talking about OOABL!
"It is actually a philosphy of how to program." - totally agree with this.
I've worked a lot with OO and not OO concepts and my understanding "it is just a tool" applys to "OO is not the only right concept to write a code"
I find it very useful for system task projects or for interface part, where there a lot reuseable components and number of objects is limited.
But DB itself is Set of objects. And most DB use-cases do not work with 1 object. And i feel very frustrated when I try to put those sets into classes, which focuses on 1 object processing. It is why concepts of ProdataSets and temp-tables under OO philosophy do real work
"produces is a true thing of beauty."
"Beauty" concept should be changed to "applicable to real tasks" concepts.
Abe, I know you, bacause you have a few public OO ABL opensource projects, published on github.
Check your Excel project and your own comments about it. They focus on how bad ABL works with objects, how it slow and consume a lot of memory... etc
It is just a whinings. My external point of view just see "wrong architecture", used for a task.
We have almost the same project, that uses temp-tables to work with cells of excel file and methods to change it. We dont use any OO elements, but it works under OO philosophy.
So beautiful concept is not always really beautiful.
Maxim.
To be sure, one has to do mapping at the RDBMS boundary, but it sounds to me like you are not really doing that mapping. By preserving the relational structure in the BL, you have something that is not really an object instead of structuring the solution in terms of objects and relationships. You are never going to get Single Responsibility Principle that way, but instead are going to have at best put OO window dressing on what is still traditional RDM code. One isn't going to get reuse that way nor encapsulate all the logic about any entity in one place. Rather, one is going to persist having bit and pieces of logic scattered here and there.
Take the classic case of something like Order which has multiple types and delegates. In good RDBMS design ... regardless of what philosophy is in the code ... the data elements unique to a type are going to be in a separate table as are the data elements that apply to a delegate. In the typical ABL application, these are all mushed together in one record with conditional logic in the code to pull apart the elements into type appropriate behavior. Yes, you can do that. Yes, the schema is simpler. But, it isn't good database design no matter how you are accessing it. It isn't normalized. One can map that nicely on to an OO structure and deal with the real structure of the data elements and associated behavior in a way that is directly parallel to the problem space. Even if one is going to construct a PDS, one should be doing the same kind of decomposition to isolate the wrongness of the DB.
And most DB use-cases do not work with 1 object. And i feel very frustrated when I try to put those sets into classes, which focuses on 1 object processing. It is why concepts of ProdataSets and temp-tables under OO philosophy do real work
Excellent statement, which is true for any UI and batch processing. The ability to work with large sets of data (more than 3 customers) is a key criteria for judging any implementation of business logic in the ABL - no matter if procedural or OO or a mix of both. People love the ABL because of the ability to work with (large) sets of data with ease.
Even if one is going to construct a PDS, one should be doing the same kind of decomposition to isolate the wrongness of the DB.
Yes. But the ProDataset and it's helpers are great at doing that.
There is a challenge with sub-classing though. As a base Order temp-table structure and Order temp-table for a "subtype" are not type-compatible in the OO sense. Dynamic coding - one way around this - in the BL is a pain and should be avoided. Sourcing ProDatasets from ProDatasets to do a "type conversion" is one possible approach around this key issue (expensive type of a CAST).
But still for very common tasks like accumulating order line value by criteria's like a VAT rate, product group or shipment parameters the relational access to the data in the ProDataset is superior (I'm still open to get convinced of something different).
But it looks like no matter how you are coding you need to bite a bullet.
maximmonin wrote:
"It is actually a philosphy of how to program." - totally agree with this.
I've worked a lot with OO and not OO concepts and my understanding "it is just a tool" applys to "OO is not the only right concept to write a code"
I find it very useful for system task projects or for interface part, where there a lot reuseable components and number of objects is limited.
I guess you could call OO a philosophy. I think philosophy applies more cleanly to ideas like Agile or Extreme programming. I prefer Wikipedia's choice of word - paradigm. There is more to programming paradigms than just procedural or OO; I know back at university we did some functional (Scheme and Lisp) and logic (Prolog) as well. The functional languages are good at things like sifting through massive amounts of data quickly (i.e. data mining); logic are good for AI research. Procedural still has a place, but I think it's more for things that are speed and memory critical, like kernels (I believe the Linux kernel still only runs C... I could be mistaken). I think OO will continue to dominate most user-mode programs, and will continue to replace procedural code as the old-timers die out.
But DB itself is Set of objects. And most DB use-cases do not work with 1 object. And i feel very frustrated when I try to put those sets into classes, which focuses on 1 object processing. It is why concepts of ProdataSets and temp-tables under OO philosophy do real work
A relational database doesn't encapsulate objects very well. There are object-relational mapping (ORM) frameworks that do mappings between RDBMS' and OO code, but they have to overcome an impedance mismatch, which can only be done in languages that have strong OO support (OOABL is nowhere near this, and I very much doubt it will get there in the foreseeable future).
The "1 object processing" you are talking about sounds like Martin Fowler's ActiveRecord pattern, which is just one method of ORM that maps one table to exactly one class instance object. There are more complicated patterns out there, such as another Fowler pattern called DataMapper, which handles more complicated scenarios much better.
Let's say I want to fetch all customer's that bought a blue item from me. Let's contrast between how I would do this in OpenEdge and how I would do it Ruby's DataMapper implementation:
OpenEdge
DEFINE TEMP-TABLE ttCustomers
FIELD iCustNo AS INTEGER
FIELD rowid AS ROWID
INDEX IXPK iCustNo IS PRIMARY UNIQUE.
FOR EACH item NO-LOCK
WHERE item.sku MATCHES "*BLUE*":
FIND FIRST order-line
WHERE order-line.item-no EQ item.item-no
NO-LOCK NO-ERROR.
IF AVAILABLE order-line THEN DO:
FIND FIRST order NO-LOCK OF order-line.
FIND FIRST customer NO-LOCK OF order.
IF NOT CAN-FIND(FIRST ttCustomer
WHERE ttCustomer.iCustNo EQ customer.cust-no) THEN DO:
CREATE ttCustomer.
ASSIGN ttCustomer.iCustNo = customer.cust-no
ttCustomer.rowid = ROWID(customer).
END.
END.
END.
Ruby (DataMapper gem)
Customer.all(Customer.orders.order_lines.item.sku.like => "%BLUE%")
Note that this is an unfair example, since Ruby actually returns all attributes of the Customer while OpenEdge is just returning a cust-no and a ROWID.
If you still think that Ruby's implementation is wrong... then baby, I don't wanna be right!
P.S. ORM is old hat nowadays to most OO developers. The current hot topic is NoSQL, typically in the form of document-oriented databases like MongoDB or CouchDB (not to replace RDBMS entirely, but just for the most part).
maximmonin wrote:
"produces is a true thing of beauty."
"Beauty" concept should be changed to "applicable to real tasks" concepts.
I think you'll find that there is plenty of code out there that is elegant and applicable to real tasks. I still think it is beautiful.
Abe, I know you, bacause you have a few public OO ABL opensource projects, published on github.
Hah, did you think I forgot? I remember that you forked my Stomp Client framework. Might I take a moment to convert you to using git instead of SVN? Nah, I'll do that later...
Check your Excel project and your own comments about it. They focus on how bad ABL works with objects, how it slow and consume a lot of memory... etcIt is just a whinings. My external point of view just see "wrong architecture", used for a task.
It is definitely whining. I do tend to do that about things that are out of my control, but make my code look bad. What's that old saying? The squeaky wheel gets the grease?
I agree that to a degree it is simply using the wrong tool for the job, i.e. OOABL sucks for some things. But then again, in order for OOABL to ever improve, I believe it should get pushed to it's limit and its flaws should be loudly vocalized. Who knows, maybe someday it will turn into something more useful from it? I know I won't be around to see it though.
We have almost the same project, that uses temp-tables to work with cells of excel file and methods to change it. We dont use any OO elements, but it works under OO philosophy.
Somehow I doubt that. Is this an external .p file that takes in parameters? How about if you want to add a parameter to it? You have no constructor overloading so have fun with those recompiles. Or you can rename it myprogram2.p.... lol
(OOABL is nowhere near this, and I very much doubt it will get there in the foreseeable future).
In that case you either have to accept that or try to get influence on PSC to move the product to the direction that you believe is the right one.
mikefe wrote:
Even if one is going to construct a PDS, one should be doing the same kind of decomposition to isolate the wrongness of the DB.
Yes. But the ProDataset and it's helpers are great at doing that.
There is a challenge with sub-classing though. As a base Order temp-table structure and Order temp-table for a "subtype" are not type-compatible in the OO sense. Dynamic coding - one way around this - in the BL is a pain and should be avoided. Sourcing ProDatasets from ProDatasets to do a "type conversion" is one possible approach around this key issue (expensive type of a CAST).
But still for very common tasks like accumulating order line value by criteria's like a VAT rate, product group or shipment parameters the relational access to the data in the ProDataset is superior (I'm still open to get convinced of something different).
But it looks like no matter how you are coding you need to bite a bullet.
Temp-tables and Prodatasets are both garbage because you aren't escaping from the "relational" world. You're just repeating the database schema all over your code. In the modern coding world, there are plenty of ORMs that handle inheritance. Even Ruby's old ActiveRecord gem, which implements the Fowler pattern of the same name (which doesn't strictly support inheritance as described by Fowler), improved upon the original by adding inheritance and associations.
Somehow I doubt that. Is this an external .p file that takes in parameters? How about if you want to add a parameter to it? You have no constructor overloading so have fun with those recompiles. Or you can rename it myprogram2.p.... lol
Parameter objects have their place in procedural ABL as well.
mikefe wrote:
(OOABL is nowhere near this, and I very much doubt it will get there in the foreseeable future).
In that case you either have to accept that or try to get influence on PSC to move the product to the direction that you believe is the right one.
I've accepted it. As mentioned I won't be a member of this microcosm for a great deal longer so it doesn't particularly bother me.
Temp-tables and Prodatasets are both garbage because you aren't escaping from the "relational" world. You're just repeating the database schema all over your code.
You say you can't abstract the DB schema in ProDatasets? I can.
mikefe wrote:
Temp-tables and Prodatasets are both garbage because you aren't escaping from the "relational" world. You're just repeating the database schema all over your code.
You say you can't abstract the DB schema in ProDatasets? I can.
And how about behavior?
tamhas wrote:
Check out my website in a couple of days for a presentation on OO best practice. And, yeah, I'm talking about OOABL!
I'll check it out!
mikefe wrote:
Somehow I doubt that. Is this an external .p file that takes in parameters? How about if you want to add a parameter to it? You have no constructor overloading so have fun with those recompiles. Or you can rename it myprogram2.p.... lol
Parameter objects have their place in procedural ABL as well.
If I'm understanding the implication of this, then it sounds like God-awful design. I can't think of any place where this is a better idea than simple method overloading or a behavioral design pattern like Strategy. Please, for God's sake, set me straight.
And how about behavior?
No. That's separated from the data. But that will still allow me to create reusable code. Do you disagree? Maybe not encapsulated with the data. But the ABL has other benefits. There would be a big rush away from it if not.
You've obviously made your choice to go with another language in the future. Good luck with that.
If I'm understanding the implication of this, then it sounds like God-awful design.
Please explain.
mikefe wrote:
And how about behavior?
No. That's separated from the data. But that will still allow me to create reusable code. Do you disagree? Maybe not encapsulated with the data. But the ABL has other benefits. There would be a big rush away from it if not.
You've obviously made your choice to go with another language in the future. Good luck with that.
I'm sure you'll be sad to see me go... haha
I'm sure you'll be sad to see me go... haha
That's more a question to debate with your Progress salesrep or employer.
mikefe wrote:
If I'm understanding the implication of this, then it sounds like God-awful design.
Please explain.
Yes I should have just done that from the start. I understood it to mean you have a Parameter object that you use in many programs that's purpose is to encapsulate parameters.
E.g.
CLASS Parameter:
...
METHOD PUBLIC VOID AddParameter(INPUT ipcParamName AS CHARACTER, INPUT ipcParamValue AS CHARACTER):
METHOD PUBLIC CHARACTER GetParameter(INPUT ipcParamName AS CHARACTER):
...
END CLASS.
used like this:
CLASS Foo:
CONSTRUCTOR PUBLIC Foo (INPUT ipobjParameter AS Parameter).
END CLASS.
CLASS Bar:
CONSTRUCTOR PUBLIC Bar (INPUT ipobjParameter AS Parameter).
END CLASS.
... etc.
Say it ain't so, Joe!
I'm not quite sure what you are saying here. I *think* you are agreeing that, regardless of the mucky way the data happens to be stored that the right thing to do is to parse it into separate tables and subtables by type and delegate. I *think* we probably even agree that the principles for deciding on the "right" structure have mostly to do with normalization and thus is not dependent on whether one is going to use the data in traditional ABL or in OOABL. I also think we agree that PDS are good tools for doing this kind of mapping.
Beyond that, I'm not sure where we are.
Say it ain't so, Joe!
Damn, I have the feeling you are that disappointed that you intentionally try to make everything bad. I hope you get to relax over the holiday season.
To stick with the context of Excel export:
CLASS ExcelExportParameter IMPLEMENTS IExcelExportParameter:
DEFINE PUBLIC PROPERTY WorksheetName AS CHARACTER ...
DEFINE PUBLIC PROPERTY WorksheetRange AS WorksheetRange...
END CLASS .
No AddParameter... If I would have thought into that direction, I could as well have recommended the DYNAMIC-CALL.
The actual procedure would need just a single parameter (the parameter object). In that procedure you could test the type (Interface) of the parameter object and eventually perform different action. That's not really method overloading, but it could be still handled in the procedure and I still consider that well encapsulated.
Please explain in your own words (without taking the help from Wikipedia or Martin Fowler) what's "god awful design".
And please take into consideration that Maxim' procedural implementation seems to perform better than an OO implementation and you were asking for a solution to the additional parameter issue.
There is nothing about OO which presents a difficulty in dealing with large amounts of data. Moreover, if one exclude use cases like browser/grid oriented UI, even when one is processing large amounts of data, the normal processing is sequential, i.e., even though a large amount of data goes through the processing in the end, only one set of the data is being worked on at a time. There are exceptions, of course, like trend analysis, which inherently involve matrixes of data, but they are exceptions.
I don't see why one should define one's layer interface and processing structure around the exception.
BTW, we have thoroughly hijacked this thread.
Might I take a moment to convert you to using git instead of SVN? Nah, I'll do that later...
Would that I could convert you both to using OE Hive so that people could actually find this stuff instead of having to accidentally run across a reference in some forum thread.
Somehow I doubt that.
On that I think we agree ... heck, even most OO isn't actually very good OO so my expectation of "not OO, but like OO" is pretty low. Not to say that it isn't possible.
Please, for God's sake, set me straight.
That seems unlikely!
But, Mike is at least partly right. There is a place for parameter objects. But, you are right that this doesn't mean that every contract should become a parameter object to avoid ever having to change a signature. Both parameter objects and method overloading have a role. You are right that one doesn't have the simple mechanism of overloading to simultaneously support the old contract and a new one, but I'm not sure how material that is. If the contract is changing, then the contract is changing and one is going to change the signature in both cases. If the contract is being added to, then one probably wants to leave the existing contract in place and provide a new signature for the new data item. This is true whether one is dealing with methods or procedure calls.
I'm sure you'll be sad to see me go... haha
Not us. Sometimes, one loses a member of the "flock", but that doesn't mean that one is happy to see them go. Better would be to convince you that it was good to stay.
Sure, Progress has it's flaws. However, I can tell you that despite
it's flaws, it has given me a bloody good living over the past 20
years, and from what I've seen recently, it is going to give me at
least that over the next 20.
Thank you Progress. My wife thanks you. My 5 kids thank you - because
everything I have and own I owe to being a Progress developer.
Julian.
On 18 December 2010 20:22, Thomas Mercer-Hursh
mikefe wrote:
Say it ain't so, Joe!
Damn, I have the feeling you are that disappointed that you intentionally try to make everything bad. I hope you get to relax over the holiday season.
Yeah I'm pretty much stressed to the max at the moment. I'll probably die an early death, lol
The actual procedure would need just a single parameter (the parameter object). In that procedure you could test the type (Interface) of the parameter object and eventually perform different action. That's not really method overloading, but it could be still handled in the procedure and I still consider that well encapsulated.
It's better than what I had assumed. I guess I'm just a pessimist?
Please explain in your own words (without taking the help from Wikipedia or Martin Fowler) what's "god awful design".
Woah call off the dogs there buddy... I only linked to a few things so people would have an easy reference to some topics I haven't seen talked about on this forum. It's not a substitute for my own knowledge. If you prefer I'm sure there's a setting on here that you can disable hyperlinks if it offends you so much. The bad design I was talking about is the exact code snippet I posted. That's what formed in my head reading the ambiguity of the words you wrote.
And please take into consideration that Maxim' procedural implementation seems to perform better than an OO implementation and you were asking for a solution to the additional parameter issu
I don't know what you mean by take into consideration? If his performs better that way that's fine. My point is if Progress implemented OOABL perfectly, there should only be a marginal speed difference between a perfect OO and perfect procedural version. I would trade the negligible speed drop for the code reuse and readability benefits any day. I don't fault him for writing something procedurally if the speed matters; I only cautioned him to not take the defects of OOABL and apply it to all OO languages with the same brush.
tamhas wrote:
Might I take a moment to convert you to using git instead of SVN? Nah, I'll do that later...
Would that I could convert you both to using OE Hive so that people could actually find this stuff instead of having to accidentally run across a reference in some forum thread.
I wouldn't mind it if my projects got forked over to the OE Hive, but I will always consider my github account to be the primary home for all of my personal open source projects. It shouldn't really matter after I leave this job, as I won't be doing any more commits to them.
tamhas wrote:
Please, for God's sake, set me straight.
That seems unlikely!
My wife would agree.
But, Mike is at least partly right. There is a place for parameter objects. But, you are right that this doesn't mean that every contract should become a parameter object to avoid ever having to change a signature. Both parameter objects and method overloading have a role. You are right that one doesn't have the simple mechanism of overloading to simultaneously support the old contract and a new one, but I'm not sure how material that is. If the contract is changing, then the contract is changing and one is going to change the signature in both cases. If the contract is being added to, then one probably wants to leave the existing contract in place and provide a new signature for the new data item. This is true whether one is dealing with methods or procedure calls.
I will acknowledge that they have a role. It might just be my own personal preference, but I would use them as a last resort or under special circumstances only for a language like OOABL. I have seen them used more in languages like Perl and Ruby where hashmap support is native and lends itself well to this type of thing (i.e. you don't have to write a whole Parameter class just to push them around).
My point is if Progress implemented OOABL perfectly
One has to look at thoughts like this carefully. ABL is a pseudo-compiled language and a 4GL. The plus in this is that the compiled code is relatively compact for what it does and consequently loads quickly. The negative is that fairly simple operations still require the AVM to process the p-code to figure out what to do and this can be surprisingly slow for simple operations. People are periodically posting results of some tight loop doing no more than incrementing an integer and whining about how much slower it is than Java or C# or something. But, applications are normally not made out of tight loops adding 1 to some integer 1000000 times. When one looks at overall applications, ABL doesn't perform that poorly, in large part because these inefficiencies are balanced by other places where the code is very efficient because very small amounts of ABL code correspond to very sophisticated behaviors. The built-in transaction scoping and roll back is an example.
The same issue applies to OO code in almost any language. Using good OO design principles like loose coupling often introduces a certain inefficiency in the application that wouldn't have to be there. But, the trade off is long term evolution and maintenance of that application is so much better with loose coupling that it is worth some run time efficiency in most cases. Of course, if you are writing code for RT/E applications like controlling guided missles, then absolute performance may trump maintainability.
In the same way, traditional ABL trumps most languages in ease of maintenance and easy modifiability ... particularly if written according to good design principles. OOABL should be that much better, even if one pays a bit for this in absolute execution speed.
We do know about a couple things about OOABL where the performance seems worse than it has to be. E.g., you will find a thread on the OO forum (which is probably where this discussion belongs) about the run time penalty for inheritance. It is being explored. I'm not convinced it is critical.
Point being that there are lots of things where it doesn't matter if A is absolutely as fast as B as long as A is fast enough for the requirement.
We don't fork other people's projects over the OE Hive. We invite them to post their material on the Hive. I think we have all the goodies necessary to host active projectes with multiple developers including SVN, forums, issue lists and tracking, etc. But, frankly, for one person projects which are largely publish and forget, then a simple attachment is sufficient. One can come back and update the attachment periodically, if desired and appropriate. Book pages provide the nested structure which one might want in writing documentation, but for a simple contribution, a single page may suffice. We don't even have any objection to your posting pure text including links that point to the place where the software can be downloaded. We understand that some people want to host their stuff on their own site. We also have cases where people have svn repositories on their own machine which they sink periodically to the one on OE Hive.
The point is that not only do we offer most of what you can get elsewhere, but we offer visibility. We have lots of visitors and all, except the robots, are people related to the Progress Community, not people who were actually looking for a Java routine and found yours by accident.
I will acknowledge that they have a role.
It isn't a question of desperation but of fitness for purpose. For something like returning information in generic error handling routines it is hard to think of anythng better since sometimes there is almost nothing to pass back and sometimes a lot.
tamhas wrote:
My point is if Progress implemented OOABL perfectly
....
The same issue applies to OO code in almost any language. Using good OO design principles like loose coupling often introduces a certain inefficiency in the application that wouldn't have to be there. But, the trade off is long term evolution and maintenance of that application is so much better with loose coupling that it is worth some run time efficiency in most cases. Of course, if you are writing code for RT/E applications like controlling guided missles, then absolute performance may trump maintainability.
Did you read the very next sentence I wrote? That was my exact point in fact. There should only be a very minimal performance difference, which is vastly outweighed for most applications by the code reuse and readability OO offers.
In the same way, traditional ABL trumps most languages in ease of maintenance and easy modifiability ... particularly if written according to good design principles.
I'll agree to disagree here.
We do know about a couple things about OOABL where the performance seems worse than it has to be. E.g., you will find a thread on the OO forum (which is probably where this discussion belongs) about the run time penalty for inheritance. It is being explored. I'm not convinced it is critical.
Weird. Can't say I've noticed that one.
tamhas wrote:
We don't fork other people's projects over the OE Hive. We invite them to post their material on the Hive. I think we have all the goodies necessary to host active projectes with multiple developers including SVN, forums, issue lists and tracking, etc. But, frankly, for one person projects which are largely publish and forget, then a simple attachment is sufficient. One can come back and update the attachment periodically, if desired and appropriate. Book pages provide the nested structure which one might want in writing documentation, but for a simple contribution, a single page may suffice. We don't even have any objection to your posting pure text including links that point to the place where the software can be downloaded. We understand that some people want to host their stuff on their own site. We also have cases where people have svn repositories on their own machine which they sink periodically to the one on OE Hive.
The point is that not only do we offer most of what you can get elsewhere, but we offer visibility. We have lots of visitors and all, except the robots, are people related to the Progress Community, not people who were actually looking for a Java routine and found yours by accident.
I can see the benefit to having all the OE stuff in one place, for sure. I'll try to get my stuff over there when I have some time. Thanks for the info.
abevoelker wrote:
It is definitely whining. I do tend to do that about things that are out of my control, but make my code look bad. What's that old saying? The squeaky wheel gets the grease?
I agree that to a degree it is simply using the wrong tool for the job
You mentioned different patterns for OO. Excel report projects shoundnt focus on Cell object.
Just because to write simple reports with 50000 rows and 20 columns you have to create 1 mln objects with 20 variables each.
And call 3-5 mln methods to output it.
It will be slow and consume a lot of memory. It is what I call "wrong architecture" ("God awful design" - is your words).
But multiply db records per object is not "main" pattern. Almost all projects focus on 1 record per object pattern. Just because it makes code more reuseable.
But even if projects focuses on set of objects under OO concept it still has a lack of some features. For example, finding within a set. Sequentual search isnt good and limit set for 1000 objects (for most tasks)
The method I use is quite simple. I use prodatasets/temp-tables to store set with whole bunch of data. It has indexes, so it isnt a problem to find out something within a set. And all code just incapsuletes this set of data.
Tamhas calls it "a window". I agree with it. It is not real OO concept. But it doesnt mean that this style is not reusable.
Actually to output to excelxml right now I just write:
{libs.i}
tab2xml ("tablename1,temp-tablename2,tablenameN").
It is common use-case.
Maxim.
Seems to me that what we have here is a failure in decomposition. If one is writing a routine to export to a spreadsheet, why in the world is one creating an object for every cell. You aren't calculating with it or anything. The focus is one interface. No reason to create a million of anything.
This is why I keep mentioning trend analysis. This is inherently a matrix problem. Even OO people don't define objects for each cell in the matrix because it is the matrix as a whole that one wants to calculate on. Thus, one object.
Seems to me that what we have here is a failure in decomposition. If one is writing a routine to export to a spreadsheet, why in the world is one creating an object for every cell. You aren't calculating with it or anything. The focus is one interface. No reason to create a million of anything.
I guess we can agree that for most problems there is more than a single right strategy for decomposition.
But a fact is that the ABL is slower with creating objects that languages like C# are. Creating 1.000.000 objects (let's say Excel or UltraGrid cells) performs acceptable on C# (time and memory wise). So in order to choose the right design for an actual task one needs to accept a characteristics of the target platform.
That is what makes an architect good or bad as well.
Obviously, if a preferred architecture has performance problems, one has to consdier other architectures. This happens all the time in 3GL OO solutions as well, particularly those involving time-critical elements. But, it is something one does as a recognized exception to what one would otherwise do as best practice ... lots of apologies in the comments and that sort of thing. What I am seeing in ABL though, is a lot of presumptive action. No actual test, just a choice of an alternate architecture based on presumptive performance advantage and done universally, not as an exception.
You mentioned different patterns for OO. Excel report projects shoundnt focus on Cell object.
I actually had been meaning to add a Row class and make that the default way of populating the worksheets, which would help performance quite a bit. I don't really have the time, though, and it works just fine using Cells for all the tasks I need it for (typically
Just because to write simple reports with 50000 rows and 20 columns you have to create 1 mln objects with 20 variables each.
I'm not sure I'd call a 50,000 row spreadsheet a "simple report". I'd actually say it is pushing the usefulness of a spreadsheet to its limit... you could almost say it's the "wrong architecture" (your words )
Bu)t multiply db records per object is not "main" pattern. Almost all projects focus on 1 record per object pattern. Just because it makes code more reuseable.
I think you're referring to the ORM stuff I mentioned? If so, the reason for that is because ORM is typically for projects that already have classes and need to persist them to DB. It's much more rare to have an existing DB schema and try to map it into class structures. DataMapper works quite well at this for the most part, but I doubt anything will do a perfect job since the relational schema wasn't designed with object structures in mind.
But even if projects focuses on set of objects under OO concept it still has a lack of some features. For example, finding within a set. Sequentual search isnt good and limit set for 1000 objects (for most tasks)
Hunh? This might be a limit for OOABL, but not for most OO languages. For one, there's no reason to do a sequential search if you are using the right datatypes to store your data in (trees, maps, whatever). Handling sets shouldn't be too hard either... Java does quite well with its Collections interfaces. Access using Iterators is flexible (and not slow, if done properly) as well.
Actually to output to excelxml right now I just write:{libs.i}
tab2xml ("tablename1,temp-tablename2,tablenameN").
It is common use-case.
Maxim.
Yeah we've all got our own style. Include files are useful, but can necessitate program recompiles when changed.
tamhas wrote:
Seems to me that what we have here is a failure in decomposition. If one is writing a routine to export to a spreadsheet, why in the world is one creating an object for every cell. You aren't calculating with it or anything. The focus is one interface. No reason to create a million of anything.
This is why I keep mentioning trend analysis. This is inherently a matrix problem. Even OO people don't define objects for each cell in the matrix because it is the matrix as a whole that one wants to calculate on. Thus, one object.
As I mentioned to Maxim, it isn't a shining example of perfect design, but it gets the job done for small-medium sized documents. The muddling factor is that Excel applies "styles" (different fonts, colors, shading, borders, etc.) on a per-cell basis, so the naive solution is to start with a per-Cell populating mechanism. I never really got around to it, but I always wanted to add a Row class and have that as the preferred method for population. I think that would improve performance quite a bit. I know that's how the Apache POI does it.
mikefe wrote:
Seems to me that what we have here is a failure in decomposition. If one is writing a routine to export to a spreadsheet, why in the world is one creating an object for every cell. You aren't calculating with it or anything. The focus is one interface. No reason to create a million of anything.
I guess we can agree that for most problems there is more than a single right strategy for decomposition.
But a fact is that the ABL is slower with creating objects that languages like C# are. Creating 1.000.000 objects (let's say Excel or UltraGrid cells) performs acceptable on C# (time and memory wise). So in order to choose the right design for an actual task one needs to accept a characteristics of the target platform.
That is what makes an architect good or bad as well.
I've found the same thing, Mike... object creation is quite slow (even for the most primitive class, with no parents and only a single private variable).
I would add that it seems there is a large amount of memory allocated for each object. I'm not sure what the cause of that is, but I know wish I could see how a CHARACTER variable handles dynamic memory allocation. I have a sneaking suspicion these variables start with a greedy allocation by default. It's the reason I played around with writing String/StringBuilder classes using MEMPTRs (the code is on github)
abevoelker wrote:
I actually had been meaning to add a Row class and make that the default way of populating the worksheets. Feel free to improve upon it.
I'm not sure I'd call a 50,000 row spreadsheet a "simple report". I'd actually say it is pushing the usefulness of a spreadsheet to its limit... you could almost say it's the "wrong architecture" (your words )
We use complety different internal architecture.
It is based on Excel template reading from file, copying regions from templates (with attributes and values), and putting report values.
Yeah, we use temp-tables to keep all those data. Just because last operation (put values upon template) requires searching. And classes arent suitable for this operation.
About large reports. We have many GB databases, and some reports just used for Excel Olap Analisys. It is our use-case.
Maxim.
tamhas wrote:
The focus is one interface.
Actually my focus is use-cases. And how project interface meets requierement for those use-cases.
It doesnt matter does it use OO internal arctitecture, or use procedure/function calls with sets of input/output parameters.
The only that matters - is it suitable or not.
It's much more rare to have an existing DB schema and try to map it into class structures.
Why? Isn't this the case whenever there is an existing application and a desired to move to OO for future development? For transformation to a new architecture, one hopes that the schema will get visited too, but during transition, one probably will use the existing schema ... one of the virtues of a data layer.
I have to agree that there is a fundemental misconception about "finding within a set". Speaking in those terms betrays being stuck in an RDM mindset. Yes, there are key/value collections where one can find by key, but they are rarely used since normal processing is to select an appropriate set into a collection and then process every record in the set. Yes, there are exceptions, but think about it ... isn't one mostly doing the same thing to every member?
I also agree with you that, while include files were a convenient way to do ths sort of thing 25 years ago, they are a poor tool in modern programming. Much better to encapsulate that logic properly. I just ran into some code which was full of RUN statements which I thought must be running an IP in a super since there was no path, no .p, and no corresponding IP. Turned out that there was a corresponding IP ... buried in an include. Yuck!
Getting the required job done in an adequately performant way is obviouisly an important criterion, but it isn't the only one. Maintainability, stability, ease of modification, graceful evolution in response to changing requirements ... among other criteria are also important ... potentially more important over time than whether the function minimally did the job in the first iteration.
I have to agree that there is a fundemental misconception about "finding within a set". Speaking in those terms betrays being stuck in an RDM mindset. Yes, there are key/value collections where one can find by key, but they are rarely used since normal processing is to select an appropriate set into a collection and then process every record in the set. Yes, there are exceptions, but think about it ... isn't one mostly doing the same thing to every member?
Thomas, I have to disagree with that as I believe that it's not an exception that one needs to select in/on information in the BL layer as well. I'm not saying that every form of processing will require selection in the BL, but enough to keep it a relevant fact, a very relevant fact. Technologies like LINQ (without wanting to start a debate about the quality) and the adoption ratio definitively prove that even in a pure OO business logic layer there is a need for a flexible selection of information (may that be records or objects).
var query = from p in products
where p.Name.StartsWith("A")
orderby p.ID
select p;
I also agree with you that, while include files were a convenient way to do ths sort of thing 25 years ago, they are a poor tool in modern programming. Much better to encapsulate that logic properly. I just ran into some code which was full of RUN statements which I thought must be running an IP in a super since there was no path, no .p, and no corresponding IP. Turned out that there was a corresponding IP ... buried in an include. Yuck!
The same can happen to an OO developer as well. There are always possibilities of ambiguous qualifiers. A variable can overly a property, a property (reference type) can overlay a static type etc... Not to speak about DB qualifiers coming into play (and the confusing error messages that may cause).
You would mention LINQ ... hopefully certain persons aren't listening since we have already badly hijacked this thread. We don't need to start on a separate new direction!
Note that I am not saying that one never needs to select. Just that most often the selection occurs in building the collection, not picking out individual cases withn the collection. Some of this is a difference in usage pattern. E.g., suppose one has some set of order lines. For starters, these order lines are selected for the collection because they are the order lines of the current order. Then lets suppose we have a discounting structure which is based on total quantity within a category.
In traditional ABL we would have one temp-table indexed by both order line and by product category (non-unique). When we needed to total up the quantity of the lines within a category, we would do a for each using the category index to find the matching records for the category of interest. In an OO solution. we would have one collection which was all the lines and additional collections, one per category. We would have no more objects, just collections. To get a total for lines in a category, we would process all the lines for the collection corresponding to that category, NOT process the main collection selecting lines.
And, of course, there are key/value pair collections when you need them.
And, of course, there are key/value pair collections when you need them.
Just for the record: Those are typically usable for equality matches. LINQ can handle more. More like a DB query language.
tamhas wrote:
It's much more rare to have an existing DB schema and try to map it into class structures.
Why? Isn't this the case whenever there is an existing application and a desired to move to OO for future development? For transformation to a new architecture, one hopes that the schema will get visited too, but during transition, one probably will use the existing schema ... one of the virtues of a data layer.
Right. What I'm saying is that in industry, ORMs are used more often for mapping existing classes to the database, not the way we descibed (i.e. the ORM itself typically gets to create the DB schema and the developer probably doesn't care what gets generated as they would rarely do a raw DB query against it). Unfortunately ORM frameworks tend to reflect this bias, and there are plenty that do not have good support for handling preexisting, legacy schemas. For example, not allowing one to map class Widget's variable Name to an existing legacy schema of "table65.widgname". Although the DB schema should surely be revisited when the code is upgraded, it is nice to have this flexibility.
I'm not going to hold my breath for something LINQ-like. I've got more basic things to ask for first. But, I think you will find the requirement covered by the collection classes proposed here http://www.oehive.org/CollectionClassesForOORelationships.
I'm skeptical, but whatever. In ABL I think we have two primary applications. One is moving to OO for an existing application where the schema and traditional ABL code already exist, but one is going to move to OO, either in a small incremental way or in a mass transformation. In either case the schema will exist and one will want to provide a data layer that maps to and from that schema and the desired object model. Downstream, one may want to revise the schema to be more like the object model when enough of that portion of the application has been transitioned. The oither is writing a new application or module where the designer is in control of both the object model and the schema and will presumably work to an easy map. Why, in the ABL world, anyone would have a bunch of OO code and no schema is beyond me.
abevoelker wrote:
i.e. the ORM itself typically gets to create the DB schema and the developer probably doesn't care what gets generated as they would rarely do a raw DB query against it). Unfortunately ORM frameworks tend to reflect this bias, and there are plenty that do not have good support for handling preexisting, legacy schemas. For example, not allowing one to map class Widget's variable Name to an existing legacy schema of "table65.widgname". Although the DB schema should surely be revisited when the code is upgraded, it is nice to have this flexibility.
Actually it is just an ideal. There are locking and transaction issues on db level in multiuser enviroment. Not just reading and writing objects to db.
Data modelling (on db level) is essential part of architecture, cause everything is about data. And i am sure that DB architect do this work better that any ORM tool.
Btw all I see that orm and linq just adding db level to existing OO application. Progress did it 20 years ago.
Btw all I see that orm and linq just adding db level to existing OO application. Progress did it 20 years ago.
That's exactly the point (unless I'd say at least 25 years ago).
By the way: This thread does again show the weakness of this forums layout. PSDN admins, help!!!
maximmonin wrote:
Actually it is just an ideal. There are locking and transaction issues on db level in multiuser enviroment. Not just reading and writing objects to db.
Obviously. That's why exceptions like OptimisticLockException, StaleObjectError, etc. get raised. You must handle the same conditions in a procedural environment as well.
Data modelling (on db level) is essential part of architecture, cause everything is about data. And i am sure that DB architect do this work better that any ORM tool.
ORM is not meant to replace DBAs, just make the process of persisting of objects to DB more efficient. You could say that computation speed is extremely important as well, but we don't program in binary/CPU instructions because we don't trust compilers to be perfect. It's healthy to use abstraction where applicable and within reason.
Btw all I see that orm and linq just adding db level to existing OO application. Progress did it 20 years ago.
There are locking and transaction issues on db level
So, one needs to do good design regardless of the programming paradigm. What's the issue. At least, with a data layer, accesses to any one table are not spread all over the code.
I was talking to my OO mentor about this Excel interface issue and he points out that reading or writing from or to Excel is directly comparable to reading or writing from or to the database. In both cases one has inherently tablular types arrangements of data. So, for that, the TT is the appropriate interface ... not one object per cell. If you were trying to create a spreadsheet written in ABL, one might have to go to one object per cell, but that would be a foolish thing to do.
I was talking to my OO mentor
Just out of curiosity, who is that?
that reading or writing from or to Excel is directly comparable to reading or writing from or to the database. In both cases one has inherently tablular types arrangements of data. So, for that, the TT is the appropriate interface ... not one object per cell.
Would this also be true when formatting information would be required of a cell by cell basis and the formatting would be of a higher complexity as just setting the font to bold? Where would you set the limit (complexity wise)?
How would you store the value of a cell? Excel stores cell values in true data types. Would you store the cell value as object references or a CHARACTER fields?
Just out of curiosity, who is that?
H.S. Lahman
http://pathfinderpeople.blogs.com/hslahman/index.html
http://www.amazon.com/Model-Based-Development-Applications-H-S-Lahman/dp/032150920X/ref=sr_1_1?ie=UTF8&s=books&qid=1292968888&sr=8-1
We argue a lot, but arguing with him sharpens my understanding!
For most Excel reporting, my expection is that one is going to have a lot of rows of consistent columns of data, which maps neatly to a TT with true data types. One needs some additional information for labels, totals, and computations, but in all likelihood that is either already in a template sheet or it is a relatively small amount of data which can be supplied as needed. No, I wouldn't force everything to character for the sake of mapping all cells to the same datatype.
tamhas wrote:
I was talking to my OO mentor about this Excel interface issue and he points out that reading or writing from or to Excel is directly comparable to reading or writing from or to the database. In both cases one has inherently tablular types arrangements of data. So, for that, the TT is the appropriate interface ... not one object per cell. If you were trying to create a spreadsheet written in ABL, one might have to go to one object per cell, but that would be a foolish thing to do.
At the risk of adding another layer of thread hijacking I'll reply. To sum it up I agree in the strict sense of the ABL world (because it is weak), but vehemently disagree wrt modern OO languages.
"TT is the appropriate interface ... not one object per cell"
This is a slightly muddy statement... let's make it crystal clear. I assume by TT you mean "a TT filled with primitive data". Also, let's be clear that the Cell objects in my code are not hanging out there in space; the Worksheet keeps track of Cell object references, and Cell objects get serialized into the Worksheet object. So the worksheet is like the TT in your statement. So the real statement is "A TT filled with primitive data is the appropriate interface... not a Worksheet object with many Cell objects".
I don't know why you think the usefulness of objects suddenly collapses when representing "tabular data". This might be true for OOABL, but doesn't apply to general OO. An object is effectively encapsulating a slice of memory with some behavior, and "tabular data" is really just a multidimensional array of said memory. You certainly can put objects into multidimensional arrays; I would say it is very useful in fact. If you have a double standard for OO I recommend steering clear of languages like Ruby, where everything is an object - even things that look like primitives!
Now, would I be correct in assuming the heart of your assertion is that there is some performance consideration to be had with creating and maintaining a lot of objects? As Mr. Fetchner pointed out, creating large amounts of small objects is not an issue at all for modern languages like C# or Java. I think this is especially true when you are creating an object and it goes out of scope shortly before creating a similar object - garbage collectors like the current JVM are now good enough to be able to reuse this memory to speed allocation of the new object. I think you will also find this use case is similar to creating many small Cell objects that get serialized into a Worksheet as each row is created.
All that being said, there is of course a little bit of memory bloat caused by wrapping primitives in objects. The temp-table does have an inherent benefit here, which is that it automatically pages to disk when it grows large enough. Luckily this really shouldn't be needed... a spreadsheet should not be large enough that it cannot be held in physical memory. If it ever did get that large, you should be using something more robust instead. In any case, you can do the same thing using classes by serializing the object to disk when it reaches a threshold (in Java you would do this by implementing java.io.Serializeable). I would, however, disagree with the usage comparison of a database, which implies the need to write the data and read it back in roughly equal measure. From the program's point of view, these documents will be simply written to disk; the need to read back the document and create an "objectified" view (reserialize) is not really there. I'd say the usage pattern is more of a write-once-read-never type of access pattern (think /dev/null).
mikefe wrote:
that reading or writing from or to Excel is directly comparable to reading or writing from or to the database. In both cases one has inherently tablular types arrangements of data. So, for that, the TT is the appropriate interface ... not one object per cell.
Would this also be true when formatting information would be required of a cell by cell basis and the formatting would be of a higher complexity as just setting the font to bold? Where would you set the limit (complexity wise)?
How would you store the value of a cell? Excel stores cell values in true data types. Would you store the cell value as object references or a CHARACTER fields?
This guy knows what's going on... I think you can see how this will get ugly fast for anything beyond bland, CSV-like reports.
P.S.
The Apache POI actually does do spreadsheet population by one-object-per-cell similar to how I do it (I was mistaken when I thought they primarily do it by Row). Do you disagree with them too?
P.P.S.
If you don't believe me wrt Java's speed, here's a loop that creates 10 million objects and takes less than 2 seconds to run on my computer:
public static void main(String[] args) {
long start = System.currentTimeMillis();
for (int i=1; i
String s = String.valueOf(i);
}
System.out.println("done in " + String.valueOf(System.currentTimeMillis() - start) + " ms");
}
Here's one that doesn't throw away the String reference at the end of the loop (note it only creates 1 million objects to not run out of memory). For 1 million objects, it is under 1 second on my machine:
public static void main(String[] args) {
long start = System.currentTimeMillis();
Vector v = new Vector();
for (int i=1; i
v.add(String.valueOf(i));
}
System.out.println("done in " + String.valueOf(System.currentTimeMillis() - start) + " ms");
}
P.P.P.S.
As mentioned in the project README, I did experiment on improving speed using the Flyweight pattern (Cell and CellManager classes), but the AVM insists on allocating an insane amount of memory for the simplest of objects (and allocation is still slow as f&$%), so it didn't help much. I was going to give Object Pooling a try, but never got around to it (Object Pooling is no longer useful in the JVM because nowadays it is smart enough to not need it).
You have a bunch of things mixed up in here ... and, I recognize that I was not sufficiently clear.
First, just because there are a lot of cells in the spreadsheet does not mean that the interface needs to deal with all of those cells simultaneously. If one is doing a lot of colors and formula and formatting and the like and not so much in the way of tabular data, then I have no problem with possibly deciding to define an object for a cell, but one does need a whole sheet full of cells at the same time. One potentially needs only one cell at a time to set up and interface and then re-use.
Now, I'm not sure how much that sort of thing is likely to be needed as an export since I would think it more likely that one would create a template, make a copy, and then add in the data. Burying all that in ABL code is creating a maintenance nightmare.
Second, the point being discussed was the context of a 20x50000 row spreadsheet. Again, I am dubious of that sort of reporting, but if that is the problem then one is mostly transferring large volumes of data, not doing fancy painting. If large amounts of data and fancy painting are required in combination, I would again expect the use of a template ... or something other than Excel.
To the extent that one is transferring large amounts of tablular data, it seems to me highly comparable to doing the same to the DB. To the extent that one is painting, even if one accesses a lot of cells, one can efficiently do so serially. There is unlikely to be a need to build a model of the full sheet and export it at once.
As for wrting a spreadsheet in ABL, as H.S., said, "this is why god invented subsystems". More to the point, he has historically talked about a variety of subsystems which are not particually well suited to OO, among these being matrix algebra problems which are inherently row and column operations. There is nothing tabular or two and column about objects so fine, create a subsystem to do the linear algebra or whatever and call it.
Your performance quibbles are an apples and oranges issue. We have known since the 1980 that there were some kinds of operations where ABL wasn't particularly performant or even quite slow. Typically, these relate to circumstances where the overhead of having to read and react to the p-code is substantial in relationship to the work being performed. E.g., if you benchmark a loop incrementing an integer from 1 to 1000000 in ABL versus C, ABL will look terrible. But, how well does that correspond to any real work? If you stick some real work inside that loop, particular database activity and the like, ABL all of a sudden doesn't look that bad. The bottom line is that for whatever its deficiencies, one can support thousands of users with terabytes of data and very high transaction volumes and do so on less hardware than is required for bigger name databases. You can't explain that by benchmarks that focus on tight loops of trivial operations.
Yes, there are things I wish were faster. I find it distressing that there is a performance penalty for inheritance, for example. Yes, I wish that one could create lightweight objects with less overhead. I'm not sure how to get there.
As Mr. Fetchner pointed out, creating large amounts of small objects is not an issue at all for modern languages like C# or Java.
Just to be precise about it, Mr Völker: I never excluded the ABL from modern languages!
abevoelker wrote:
The Apache POI actually does do spreadsheet population by one-object-per-cell similar to how I do it (I was mistaken when I thought they primarily do it by Row). Do you disagree with them too?
I have nothing against Cell interface itself. It has its use. But I just want to tell about reuse from external point of view.
For example, I am user of this projects (appache's or your's - it doesnt really matters).
I have my own need and use-cases. For example, test/debug use-case, when i just want to look TT/PDS contents, Excel Olap analysis, print document/report - which have a forms.
I decide to use some Excel project. What should i do?
First - look in documentation and check interface. This step make me sick. It has 10-20 internal objects (often more) and hundreds methods for something I know nothing about. I am reading documentation and begining to understand it's internal architecture and my path to use this project. The more versions has project, the more features it has and more objects and methods were added. Does it real value, I doubt that.
Second, I begin to use compoment.
Ok i am creatng sheet, i am creating cells and beginning to understand that to format cells in desired way i have to use tonns of methods with a lot of constants written in code. To change my form I have to rewrite all code.
Third I understand, there is still large gap between my real use-cases, and component. And I begins to build my own high level intarface. It has some procedures with fixed set of parameters. Every function do something that valueable to me. And I understand, actually i need only few functions I was talked about already (tab2xml(tables-list) + template copy + putting values). It not valuable to me what is real internal pattern used for a project. I just need a result with some quality and speed.
Simplicity, it is what really make me excite. If programmer focuses on methods and objects and forget about responsibility (in terms H.S. Lahman is talked about, thanks tamhas for reference), it leads to "puzzle project". It is really good think to play with and excite how many new features are unreavealed yet. But... not what i really want as a user. Many OO projects focuses on knowledge assosiated with object, not what object is supposed to do. It is why old function/procedure approach has its benefits.
Maxim.
Any paradigm can be executed well, but often isn't.
I haven't actually looked at any of the code, since the points raised, until now, seemed to be about the principles, not the specific implementation. But, it is certainly true that one should not need to know the internal structure and operation of this package in order to use it and that the contract of the package to the outside world should be the minimum necessary to fulfill the responsibility. ... whether it is OO or not.
tamhas wrote:
Your performance quibbles are an apples and oranges issue. We have known since the 1980 that there were some kinds of operations where ABL wasn't particularly performant or even quite slow. Typically, these relate to circumstances where the overhead of having to read and react to the p-code is substantial in relationship to the work being performed. E.g., if you benchmark a loop incrementing an integer from 1 to 1000000 in ABL versus C, ABL will look terrible. But, how well does that correspond to any real work? If you stick some real work inside that loop, particular database activity and the like, ABL all of a sudden doesn't look that bad. The bottom line is that for whatever its deficiencies, one can support thousands of users with terabytes of data and very high transaction volumes and do so on less hardware than is required for bigger name databases. You can't explain that by benchmarks that focus on tight loops of trivial operations.
How useful is a language that only performs well when doing database work? Sure, it's nice to have speedy access to data and such, but if you can't make useful transformations upon it, then why bother? This problem can only get worse going into the future.
tamhas wrote:
As for wrting a spreadsheet in ABL, as H.S., said, "this is why god invented subsystems". More to the point, he has historically talked about a variety of subsystems which are not particually well suited to OO, among these being matrix algebra problems which are inherently row and column operations. There is nothing tabular or two and column about objects so fine, create a subsystem to do the linear algebra or whatever and call it.
I had Linear Algebra and Numerical Analysis in school so I am somewhat familiar with the basics of these problem spaces (including matrix algebra). I don't know what it says
about my studiousness, but I still don't follow how this limits OO beyond the basic overhead of OO itself. Perhaps your source could give a more specific example of how OO doesn't fit into such a model, particularly applied to the idea of a spreadsheet that isn't limited to storing numeric data.
I mean, physical memory itself is only addressable by one dimension (e.g. 0x00000000 - 0xFFFFFFFF on a 32-bit system); adding a second dimension requires some abstraction. So even a plain C "subsystem" will have some slight overhead due to this abstraction. The same thing happens when you try to code a tree data structure; you are dealing with memory that is sequential, so you have to map your tree nodes into a memory structure that is sequential.
I think we get to the heart of OO here. I know not every single thing down to the bare metal can/should be object-oriented, but I believe row and column operations (i.e. multidimensional arrays) should be able to be handled just fine by using data structures provided by the standard library of the OO language in question. Now, that STL data structure itself might be highly optimized C and/or assembly language or something, but the interface it provides will still fit cleanly into the OO model.
For example, I don't see why these operations would not be very fast in a language like C++ for instance. You could do it using plain pointers. If I have a Foo object, I could maintain a multidimensional array like so:
Foo **foo = new Foo[50][50];
Traversing such an array is very fast, because pointer arithmetic is very speedy (basically just current memory address + sizeof(Foo)). Basically, each foo** is a column and each row is a foo* (or if you want, it could be vice-versa; use it how you wish). Incrementing the respective pointer (**foo++ / *foo++) would iterate through the respective columns/rows.
You might complain that the size of the array is statically defined. Well, good, because the C++ STL provides a class called Vector that implements this same behavior but also handles dynamic allocation of memory (and also fits nicely into the OO world), so you don't have to worry about buffer overflows or things like that. The Vector class may be slightly lower than using a vanilla array with a size defined at compile time, but it is often much more useful to maintain the OO abstraction than to gain the negligible speed difference. Java has its own Vector class as well, which can also be addressed in multidimensional terms by having a Vector of Vectors.
Essentially, I don't think it's worth throwing away object orientation for a spreadsheet. Maybe for the Earth Simulator or the Linux kernel.
tamhas wrote:
Yes, there are things I wish were faster. I find it distressing that there is a performance penalty for inheritance, for example. Yes, I wish that one could create lightweight objects with less overhead. I'm not sure how to get there.
Well, you could get there by using a language that already has these features / lacks these deficiencies... tee hee
mikefe wrote:
As Mr. Fetchner pointed out, creating large amounts of small objects is not an issue at all for modern languages like C# or Java.
Just to be precise about it, Mr Völker: I never excluded the ABL from modern languages!
Don't worry about it, you'll get there someday.
maximmonin wrote:
I have nothing against Cell interface itself. It has its use. But I just want to tell about reuse from external point of view.
Thanks for sharing it.
For example, I am user of this projects (appache's or your's - it doesnt really matters).I have my own need and use-cases. For example, test/debug use-case, when i just want to look TT/PDS contents, Excel Olap analysis, print document/report - which have a forms.
I decide to use some Excel project. What should i do?
First - look in documentation and check interface. This step make me sick. It has 10-20 internal objects (often more) and hundreds methods for something I know nothing about. I am reading documentation and begining to understand it's internal architecture and my path to use this project. The more versions has project, the more features it has and more objects and methods were added. Does it real value, I doubt that.
Are you talking about my code? I don't think you are because I don't have hundreds of methods; if you are, however, I disagree with your characterization of it.
Anyway, as Mr. Hursh said, ideally you really shouldn't have to look at the internal code of a framework to see what is going on. Unfortunately, OpenEdge doesn't have something equivalent to a JavaDoc so that is sometimes unavoidable if other documentation is lacking. If you are talking about my code, the example.p should give an easy intro and the CellStyle class should be the only one you need to read any method names from.
Second, I begin to use compoment.Ok i am creatng sheet, i am creating cells and beginning to understand that to format cells in desired way i have to use tonns of methods with a lot of constants written in code. To change my form I have to rewrite all code.
Yes, methods are necessary, as are passing in values to those methods. Is there any alternative? Given a clear method name, I think the method signature should be unsurprising and you end up with fairly self-documenting code.
Third I understand, there is still large gap between my real use-cases, and component. And I begins to build my own high level intarface. It has some procedures with fixed set of parameters. Every function do something that valueable to me. And I understand, actually i need only few functions I was talked about already (tab2xml(tables-list) + template copy + putting values). It not valuable to me what is real internal pattern used for a project. I just need a result with some quality and speed.Simplicity, it is what really make me excite. If programmer focuses on methods and objects and forget about responsibility (in terms H.S. Lahman is talked about, thanks tamhas for reference), it leads to "puzzle project". It is really good think to play with and excite how many new features are unreavealed yet. But... not what i really want as a user. Many OO projects focuses on knowledge assosiated with object, not what object is supposed to do. It is why old function/procedure approach has its benefits.
In other words you're being pragmatic. There's a good book on the subject, if you're interested. I think I see what you're saying: even if a framework is able to handle nearly every use case on the subject, the 'generic syntax' of the framework can become unwieldy even when trying to do simple things. I have seen a good solution to this, which is basically building a "simple" facade interface to the complicated class structure which handles the 90% of use cases (e.g. if the complicated framework is named Foo, there is a mirror framework called SimpleFoo that uses much simpler code, but is secretly actually an adapter to the Foo framework). I can't remember which framework I'm thinking of, or I would post a link.
Just remember that there are benefits to code reuse that should be taken into consideration before reinventing the wheel. Just because some projects fail to create a reusable design (mine included, perhaps?) doesn't negate the fact that it is a good general principle for many, many reasons.
How useful is a language that only performs well when doing database work?
Who said that? In fact, what I said was that ABL is empirically doing a fine job supporting thousands of users, terabytes of data, and very high transaction volumes. Of course, these are transaction oriented applications, what ABL was developed to support. It was not developed as a language in which to write multivariate analysis programs.
Point is not that you can't write a matrix processing program in Java ... the point is that it won't be very efficient either because OO is not actually very well structured for that class of program. But, as I quoted, "that's why god invented subsystems". When you need to do one of these other things for which your current language is suboptimum, then create a subsystem in the other language. If you had an ABL application that needed to control some device in one part, would you try to write the device driver in ABL? If the device had 4K of memory, would you even try to write the device driver in C++?
Unfortunately, OpenEdge doesn't have something equivalent to a JavaDoc
Have you considered AutoDoc2 http://www.joanju.com/autodox2/index.php ?
tamhas wrote:
Point is not that you can't write a matrix processing program in Java ... the point is that it won't be very efficient either because OO is not actually very well structured for that class of program.
Why can't you? What makes OO not "well structured" for the problem? You're either worried about keeping track of lots of small objects or you're worried about addressing/accessing objects in a two-dimensional manner, neither of which I think is that big of a deal.
tamhas wrote:
When you need to do one of these other things for which your current language is suboptimum, then create a subsystem in the other language. If you had an ABL application that needed to control some device in one part, would you try to write the device driver in ABL? If the device had 4K of memory, would you even try to write the device driver in C++?
Yes, I would agree with that. Indeed, if I had it my way @ work, all my ABL programs would just be a call to a "subsystem" in another language... lol
But, as I quoted, "that's why god invented subsystems".
No, I won't go there. This thread is already way off topic.
In other words you're being pragmatic. There's a good book on the subject, if you're interested. I think I see what you're saying: even if a framework is able to handle nearly every use case on the subject, the 'generic syntax' of the framework can become unwieldy even when trying to do simple things. I have seen a good solution to this, which is basically building a "simple" facade interface to the complicated class structure which handles the 90% of use cases (e.g. if the complicated framework is named Foo, there is a mirror framework called SimpleFoo that uses much simpler code, but is secretly actually an adapter to the Foo framework). I can't remember which framework I'm thinking of, or I would post a link.
Just remember that there are benefits to code reuse that should be taken into consideration before reinventing the wheel. Just because some projects fail to create a reusable design (mine included, perhaps?) doesn't negate the fact that it is a good general principle for many, many reasons.
I am architect and deal with vision (what is project about), business processes and use-cases (scenarios to use project from user point), functional requirements (what do to), and database design (what is data model at db level). I very seldom do detailed design (how to do). Most of time it is not nessesary for a projects. Those steps has nothing to do with OO, except DB design which is almost identical to object properties design. You call it pragmatic, let it be.
But you are right SimpleFoo is my focus at functional requirements level. And actually I do not care if programmer will use "modern" OO aprchoach or just set of high level functions which hides under facade whole implementation.
It happens that I observed 2 of your projects. It was very useful cause I was new to OO ABL. But you tell about reusability so it did some analisys:
Excel compoment:
for tables/temp-tables dump - useful for small tables and slow for large tables.
for print report - ok, but too low level support, no template support - useable but requires a lot of programming and hard to support my code around a component.
Total: nouseable
for MQ projects
triggering to incoming message - done perfectly, almost ready listener process.
send message - test failed - (run only as batch process)
read message - test failed - (run only as batch process)
sendfile to mq - max 50-60mb, slow listener on very big messages
transaction support - done pretty good.
Total: need some programming to suit my project needs. I spent about 2-3 weeks to make it work as I wanted. And there are still few issues to work.
You did your work pretty well, but reusability from user point of view and programmer point of view is different. Notice - I just added to your project few high level procedures (facade), one for every use-case with fixed number of parameters. Plus changed a little classes.
Maxim.
What makes OO not "well structured" for the problem?
Because the problem space for linear algebra is matrices and that has nothing to do with objects.
But, let's be more shocking. If one is doing nothing but simple CRUD processing -- filling out forms which correspond directly to database tables, OO is also not the optimum paradigm. The reason for my advocating for OOABL is that I think that there is a lot more going on in ABL applications than mere crud. And, this is not something I came up with, but something that comes from H.S. There is no holy grail, nothing perfect for everything. Everything fits best with a particular problem type.
I stopped counting at 50 languages in which I have written. They vary from small amount to hundreds and millions of lines of code. There are a number of those language which had virtues for particular problem types. A number which were interesting because of the way that they enabled one to approach some problems. Even COBOL. On the whole, I favor OO, but pretending that it is the be all and end all and nothing else matters is just silly.
tamhas wrote:
There are a number of those language which had virtues for particular problem types. A number which were interesting because of the way that they enabled one to approach some problems. Even COBOL. On the whole, I favor OO, but pretending that it is the be all and end all and nothing else matters is just silly.
That is the Point!
tamhas wrote:
What makes OO not "well structured" for the problem?
Because the problem space for linear algebra is matrices and that has nothing to do with objects.
I think you're overcomplicating matters... doing linear algebra matrice transformations != storing things in multidimensional arrays. I guess we'll just have to agree to disagree.
But, let's be more shocking. If one is doing nothing but simple CRUD processing -- filling out forms which correspond directly to database tables, OO is also not the optimum paradigm.
Maybe for the absolute simplest of CRUD. How long does that last, though? Once the software needs to evolve the point will be moot.
I stopped counting at 50 languages in which I have written. They vary from small amount to hundreds and millions of lines of code. There are a number of those language which had virtues for particular problem types. A number which were interesting because of the way that they enabled one to approach some problems. Even COBOL. On the whole, I favor OO, but pretending that it is the be all and end all and nothing else matters is just silly.
I hope you're not implying that I think OO is the be all end all. I'm not a well-seasoned industry programmer, but I like to think that in my short life as a programmer I've seen enough languages to be able to make a well-informed decision on one's utility. In school, I had a 4-credit course entitled Programming Languages in which all we did for the whole semester was explore languages in different paradigms than the procedural/OO languages that we had been using (I mentioned a few samples in a previous comment). I'm acutely aware OO is not some magical, gordian knot-cutting solution for all problems.
However, all that being said, my own naive opinion is that given a randomly picked programming task facing any programmer today, the probability that OO is the "best fit" solution out of all the other paradigms in the programmer's toolbox is higher than the others. Of course, it isn't always the case, and programmers must adjust accordingly.
Truthfully, I probably only sound like some OO nut because I'm surrounded by people daily who aren't even convinced that OO is useful in any case, so I am constantly defending it / trying to teach it. It might just be my own sensitivity to the issue, but I felt like I was detecting some of that on these forums as well. I've got my own incendiary opinions about the types of programmers that ABL breeds/sustains, but I don't have the energy to go there.
@Maxim Thanks for the reviews, but I probably won't do much with the info (sorry). Those programs were mostly written to see what OOABL could do. There are a couple things that I could probably fix, but I've encountered enough language limitations that I think the end result would be a waste of time (for example, appending CHAR to LONGCHAR gets extremely slow over time, which Progress has said is "expected behavior" so I don't think it will ever get fixed; working around this would be a PITA).
I think I should stop naively using this discussion topic as a sounding board for my own opinions, so if someone wants to contact me about something I wrote, please PM me; I don't plan on replying to the topic anymore. Also, I will sharpening some of my skills for an upcoming job hunt so it might take me a while to get back to you.
Thanks for the discussion everyone!
Once the software needs to evolve the point will be moot.
Depends on the system and the need to evolve. If you are using RAD software for the screens and the evolution is just new fields, then it can evolve just fine. If you have to do real business logic and other complex processing, then you get an advantage and motivation for OO.
And, it isn't that I disagree on tending to prefer OO for the general solution in the transaction processing space ... I do have a certain reputation as an evangelist, after all. I just have a problem with people complaining about OO not doing a particular thing well and then considering this a condemnation of OO for everything.
abevoelker wrote:
Truthfully, I probably only sound like some OO nut because I'm surrounded by people daily who aren't even convinced that OO is useful in any case, so I am constantly defending it / trying to teach it. It might just be my own sensitivity to the issue, but I felt like I was detecting some of that on these forums as well. I've got my own incendiary opinions about the types of programmers that ABL breeds/sustains, but I don't have the energy to go there.
We all learn/teach one another. Isnt it? Just, the way you thinging is too idealistics.
Programming isnt art, it is engineering. We have tasks to solve and tools to use, and we are restricted by them. We can change a tool but always there are "+" and "-".
Progress from the begining has strong side - good integration of db and bussiness layers. If you choose best BL tool - Java for example, and best DB tool - Oracle, for example, it doesnt create best tool for both layers. Because layer intergation is essential component too. If we add presentation layer we will have 5 components as total. Mixing of tools always slow down develepment cycle, just because you have to spend a lot of time to learn each tool and make them work together.
This year i've worked on web project. My choice for presentation layers was Flex. It is OO tool with 1000+ easy to use classes. All other 4 compoments (2 bridges and db + BL layers I used were from Progress). Flex has a lot async interfaces and my choice was WebService. I have spent a lot of time for intergration. It is not just sending queries and mapping results to forms or browsers. Total work imcluded also web server setup/tomcat setup/wsa setup/wsa deploy/app server setup/reogranisation on BL layer (ABL code) to face new interface. On flex part it also included mapping data to Progress datatypes, and my BL datatypes.
Yes, it is "modern" architecture and works even on my htc desire, but it really takes a lot of time especially if there are no white papers on topic.
Programming isnt art, it is engineering.
Your programs might be bolt together assemblies, but mine aren't.
Seriously, through, programming is a mix of science, engineering, and art. There is no way that decisions made in programming are all driven by mechanical rules. Art has rules too and artists must be careful about when to break them or they simply produce bad art.
What makes Java "best" when it comes to BL for intense transaction processing applications. You know what language actually dominates for these applications? COBOL.
What makes Oracle best for the DB? Because you need to buy more iron to support any given load? Because you need a full time DBA for even a small site? These are marks of goodness?
The white papers mean that it takes more time?