not a good place to start a OOP v. TOP flameware

Post #16,480 by tablizer 11/4/01 4:27:53 PM Reply	not a good place to start a OOP v. TOP flameware >> A fitting programming language for someone who loves TOP! << Actually I took a COBOL class in college. I hardly consider it "the best that p/r can do". SQL and relational tables are a clumsy add-on in COBOL. I tend to prefer dynamicly-typed (or type-free) languages descended from the Algol traditions (C, Pascal, VB, etc) that have good dictionary-array syntax, named parameters, parent scope "inheritance", etc. >> BTW, our "table oriented programming" Objects are now reading the pharmacy formats from a file, and parsing the incoming message and storing it in a database. << So. It could probably be done in assembler also. That does not mean that assember is "better". There are many ways to pie the cat. The argument is about the claim that OO pies the cat better. >> TOP and OOP can be friends, you just have to know how to do it... << You are welcome to epublish a detailed example/explanation. ________________ oop.ismad.com
Post #16,641 by gdaustin 11/5/01 3:02:20 PM Reply	Lighten Up I was just congratulating you for finding a job in my own "weird" way. I'm probably the second more obscure person here behind "Ashton". :-) As for TOP vs. OO, we've been down that road before. I think they both are good paradigms, and both have their place. When we're parsing pharmacy claims and putting them in a DB table, top is best. When we're analyzing whether a particular claim is one 'type' or 'another', or what needs to happen next, that's OO. (But, we still have a state table inside the object, so that's why I say that the two can get along...) As for COBOL, the global scope of everything drives me nuts, too. However, I've seen badly written C code with the same variable name at 2/3/4 scopes that would drive a person nuts, too. Anyway, let's drop the OOP/TOP banter now, and just bask in the afterglow of that "great new job"... Glen Austin
Post #17,440 by tablizer 11/8/01 11:42:52 PM Reply	Imma heavy >> When we're analyzing whether a particular claim is one 'type' or 'another' << I am skeptical of modeling anything in biz apps with "sub-types". You can read more about such here: (bank account "type" discussion) [link\|http://geocities.com/tablizer/bank.htm\| [link\|http://geocities.com/tablizer/bank.htm\|http://geocities.co...zer/bank.htm]] ________________ oop.ismad.com
Post #17,459 by pwhysall 11/9/01 5:50:47 AM Reply	Re: not a good place to start a OOP v. TOP flameware I tend to prefer dynamicly-typed (or type-free) languages descended from the Algol traditions (C, Pascal, VB, etc) that have good dictionary-array syntax, named parameters, parent scope "inheritance", etc. That'd be Perl or Python then. Your anti-OO mania precludes you from trying Ruby, I'm afraid. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]

Welcome to IWETHEY!