Is Procedural Paradigm a basis of OO Paradigm?
in [OOP]
|
Prev: Need advice on standardizing documentation in a project
Next: Call For Papers (Extended Deadline): WORLDCOMP'07 (June 25-28, 2007, Las Vegas, USA): computer science, computer eng., and applied computing conferences
From: topmind on 20 Mar 2007 11:21 Mark Nicholls wrote: > On 20 Mar, 06:35, "frebe" <freb...(a)gmail.com> wrote: > > > basically I can create an OO program for every procedural one, and a > > > procedural one for every OO one....but for a procedural program to > > > handle polymorphism it will contain lots of..... > > > > > if param.type == 'dog' > > > { > > > .....'woof'} > > > > > else > > > { > > > if param.type == 'cat' > > > { > > > .....'meow' > > > } > > > > > } > > > > Not if you are using function pointers and functional pattern > > matching. OO is not the only mechanism that are good at handling > > polymorphism. > > I agree, procedural decomposition with function pointers is > equivalent. > > But I excluded function pointers in a previous post. > > Without function pointers though they are not equivalent...so my > original statement stands. > > As far as pattern matching is concerned I plead ignorance, it's not > something that I believe is part of classic procedural > decomposition....I believe it used largely in functional languages, > which is another kettle of fish again. > > > > > I would also like to add that every OO application I have seen had a > > lot of "if (a instanceof A)". > > To be able to write a bad book does not discredit the language it is > written in....I don't see the relevance. > > If as I claim OO is a generalasation of pure procedural programming > then the fact one sees elements in OO that one would see in a > procedural language seems to underline the point. > > > Trying to classify functionality into > > trees of subtypes is not powerful enough for a lot of business logic. > > A multi-dimensional approach is more suitable. > > > > I do not understand in what sense it is 'multi-demensional'? Can I > assume you mean that OO constructions are single dimensional in some > sense? > > Can you explain? > > > > The OO one can polymorphically dispatch to the new behaviour supplied > > > with the type....i.e. the call graph is open. > > > > Function pointers would do the same job. > > I agree....but I explicitly excluded them in a previous post....the > question was about the procedural decomposition. Wait a second here. Are we comparing programming language features, or software design techniques? OO is just a narrow technique where function pointers and/or code snippets are put into a specific type of data structure, generally a "map", with some syntactic sugar to bind it closer to the language. I don't find maps the "magic structure" that OO'ers seem to. I have nothing against putting function pointers and/or code snippets into data structures, I would just rather have relational structures for such instead of maps of maps. Maps of maps are messier than relational in my opinion. I find consistency and logical organization with relational, but maps of maps have no discipline to them: they are the Go To of data/link structures. Maybe someday someone will find "map math", the Dr. Codd of maps. Until that day, relational is cleaner. -T-
From: Mark Nicholls on 20 Mar 2007 11:47 On 20 Mar, 15:21, "topmind" <topm...(a)technologist.com> wrote: > Mark Nicholls wrote: > > On 20 Mar, 06:35, "frebe" <freb...(a)gmail.com> wrote: > > > > basically I can create an OO program for every procedural one, and a > > > > procedural one for every OO one....but for a procedural program to > > > > handle polymorphism it will contain lots of..... > > > > > if param.type == 'dog' > > > > { > > > > .....'woof'} > > > > > else > > > > { > > > > if param.type == 'cat' > > > > { > > > > .....'meow' > > > > } > > > > > } > > > > Not if you are using function pointers and functional pattern > > > matching. OO is not the only mechanism that are good at handling > > > polymorphism. > > > I agree, procedural decomposition with function pointers is > > equivalent. > > > But I excluded function pointers in a previous post. > > > Without function pointers though they are not equivalent...so my > > original statement stands. > > > As far as pattern matching is concerned I plead ignorance, it's not > > something that I believe is part of classic procedural > > decomposition....I believe it used largely in functional languages, > > which is another kettle of fish again. > > > > I would also like to add that every OO application I have seen had a > > > lot of "if (a instanceof A)". > > > To be able to write a bad book does not discredit the language it is > > written in....I don't see the relevance. > > > If as I claim OO is a generalasation of pure procedural programming > > then the fact one sees elements in OO that one would see in a > > procedural language seems to underline the point. > > > > Trying to classify functionality into > > > trees of subtypes is not powerful enough for a lot of business logic. > > > A multi-dimensional approach is more suitable. > > > I do not understand in what sense it is 'multi-demensional'? Can I > > assume you mean that OO constructions are single dimensional in some > > sense? > > > Can you explain? > > > > > The OO one can polymorphically dispatch to the new behaviour supplied > > > > with the type....i.e. the call graph is open. > > > > Function pointers would do the same job. > > > I agree....but I explicitly excluded them in a previous post....the > > question was about the procedural decomposition. > > Wait a second here. Are we comparing programming language features, or > software design techniques? language features.....that....I've constantly said the paradigm by which the program is designed may be random. > > OO is just a narrow technique where function pointers and/or code > snippets are put into a specific type of data structure, yes......this is why I excluded them from a discussion of procedural constructions, because learning classic procedural decomposition does not involve them. > generally a > "map", with some syntactic sugar to bind it closer to the language. I > don't find maps the "magic structure" that OO'ers seem to. it's not magic, it's a semantic feature of the OO model. > I have > nothing against putting function pointers and/or code snippets into > data structures, neither have I but I excluded them in a previous post, as not part of a classic procedural toolkit. > I would just rather have relational structures for > such instead of maps of maps. Maps of maps are messier than relational > in my opinion. discusions on the relation model are irrelevant, you took exception to a statement comparing OO language features and procedural ones, and are now trying to include things that were explicitly excluded rather than simply saying. "yes you're right, if you consider procedural constructions to be WXY (and explicitly not WXY plus Z), then they are not equivalent in the scenario you have demonstrated, lets move on". > I find consistency and logical organization with > relational, but maps of maps have no discipline to them: they are the > Go To of data/link structures. > Fine....but it is not relevant....you have a relatively formal demonstration of the statement you objected to, and seemingly have no formal objection. All I have is tangental comments about constructions that are not in scope. > Maybe someday someone will find "map math", the Dr. Codd of maps. > Until that day, relational is cleaner. It is still irrelevant. Is OO > procedural in the context I have given? If not then please demonstrate by counter example. (your opinions on the relational model are for another day, and I have, as yet, not disputed them). I have accepted 'frege's comments, and pointed out that they have been excluded by a previous post, but that I agree with his comments non the less. I am at the point where I think you have demonstrated that you are not willing to discuss the matter with any sense of open mindedness, is there any point in continuing?
From: frebe on 20 Mar 2007 14:12 > > Trying to classify functionality into > > trees of subtypes is not powerful enough for a lot of business logic. > > A multi-dimensional approach is more suitable. > > I do not understand in what sense it is 'multi-demensional'? Can I > assume you mean that OO constructions are single dimensional in some > sense? When you choose to subclass a class, you are subtyping according to a given dimension. When you try to subclass by multiple dimensions, you have a problem. > > > The OO one can polymorphically dispatch to the new behaviour supplied > > > with the type....i.e. the call graph is open. > > > Function pointers would do the same job. > > I agree....but I explicitly excluded them in a previous post....the > question was about the procedural decomposition. Functions and functions pointers have been supported in many procedural languages since long time ago. The main difference is that in traditional development, you just use function pointers when you really need them. The common OO argument "I need to extend my application without recompiling the existing sources", is not that important in real life. /Fredrik
From: topmind on 20 Mar 2007 19:16 Mark Nicholls wrote: > On 20 Mar, 15:21, "topmind" <topm...(a)technologist.com> wrote: > > Mark Nicholls wrote: > > > On 20 Mar, 06:35, "frebe" <freb...(a)gmail.com> wrote: > > > > > basically I can create an OO program for every procedural one, and a > > > > > procedural one for every OO one....but for a procedural program to > > > > > handle polymorphism it will contain lots of..... > > > > > > > if param.type == 'dog' > > > > > { > > > > > .....'woof'} > > > > > > > else > > > > > { > > > > > if param.type == 'cat' > > > > > { > > > > > .....'meow' > > > > > } > > > > > > > } > > > > > > Not if you are using function pointers and functional pattern > > > > matching. OO is not the only mechanism that are good at handling > > > > polymorphism. > > > > > I agree, procedural decomposition with function pointers is > > > equivalent. > > > > > But I excluded function pointers in a previous post. > > > > > Without function pointers though they are not equivalent...so my > > > original statement stands. > > > > > As far as pattern matching is concerned I plead ignorance, it's not > > > something that I believe is part of classic procedural > > > decomposition....I believe it used largely in functional languages, > > > which is another kettle of fish again. > > > > > > I would also like to add that every OO application I have seen had a > > > > lot of "if (a instanceof A)". > > > > > To be able to write a bad book does not discredit the language it is > > > written in....I don't see the relevance. > > > > > If as I claim OO is a generalasation of pure procedural programming > > > then the fact one sees elements in OO that one would see in a > > > procedural language seems to underline the point. > > > > > > Trying to classify functionality into > > > > trees of subtypes is not powerful enough for a lot of business logic. > > > > A multi-dimensional approach is more suitable. > > > > > I do not understand in what sense it is 'multi-demensional'? Can I > > > assume you mean that OO constructions are single dimensional in some > > > sense? > > > > > Can you explain? > > > > > > > The OO one can polymorphically dispatch to the new behaviour supplied > > > > > with the type....i.e. the call graph is open. > > > > > > Function pointers would do the same job. > > > > > I agree....but I explicitly excluded them in a previous post....the > > > question was about the procedural decomposition. > > > > Wait a second here. Are we comparing programming language features, or > > software design techniques? > > language features.....that....I've constantly said the paradigm by > which the program is designed may be random. But "procedural decomposition" is a technique, not a language feature. > > > > > OO is just a narrow technique where function pointers and/or code > > snippets are put into a specific type of data structure, > > yes......this is why I excluded them from a discussion of procedural > constructions, because learning classic procedural decomposition does > not involve them. > > > generally a > > "map", with some syntactic sugar to bind it closer to the language. I > > don't find maps the "magic structure" that OO'ers seem to. > > it's not magic, it's a semantic feature of the OO model. Again, we would probably need a more precise definition of "OO" in order to dig into this deeper. > > > I have > > nothing against putting function pointers and/or code snippets into > > data structures, > > > neither have I but I excluded them in a previous post, as not part of > a classic procedural toolkit. > > > I would just rather have relational structures for > > such instead of maps of maps. Maps of maps are messier than relational > > in my opinion. > > discusions on the relation model are irrelevant, you took exception to > a statement comparing OO language features and procedural ones, and > are now trying to include things that were explicitly excluded rather > than simply saying. Procedural does not exclude relational. Oracle's engine is built in C, for example. But again this is right smack back to Turing Equivalency. I will agree that OO languages make certain design approaches (OO) *more convenient*, at least out-of-the-box, but that is not the same as being a super-set. Or are you excluding paradigms-via-libraries? For relational for the moment, procedural does not forbid putting function pointers and/or code snippets into data structures. > > "yes you're right, if you consider procedural constructions to be WXY > (and explicitly not WXY plus Z), then they are not equivalent in the > scenario you have demonstrated, lets move on". > > > I find consistency and logical organization with > > relational, but maps of maps have no discipline to them: they are the > > Go To of data/link structures. > > > > Fine....but it is not relevant....you have a relatively formal > demonstration of the statement you objected to, and seemingly have no > formal objection. > > All I have is tangental comments about constructions that are not in > scope. > > > Maybe someday someone will find "map math", the Dr. Codd of maps. > > Until that day, relational is cleaner. > > It is still irrelevant. > > Is OO > procedural in the context I have given? > > If not then please demonstrate by counter example. > > (your opinions on the relational model are for another day, and I > have, as yet, not disputed them). No they are not, per Oracle-C example. > > I have accepted 'frege's comments, and pointed out that they have been > excluded by a previous post, but that I agree with his comments non > the less. > > I am at the point where I think you have demonstrated that you are not > willing to discuss the matter with any sense of open mindedness, is > there any point in continuing? You have not demonstrated clear superset-ness of OO over procedural. If you have, I missed it. It is not my job to be open-minded for this particular issue, but to evaluate your superset claims. I honestly see no power to them. You seem to keep running into the Turing Complete wall. Again, I will agree that OO makes certain techniques easier out- of-the-box, but that is not the same as being a superset. Rather than call me "closed minded", perhaps you need to refactor your evidence. -T-
From: topmind on 20 Mar 2007 19:22
Mark Nicholls wrote: > > Trying to classify functionality into > > trees of subtypes is not powerful enough for a lot of business logic. > > A multi-dimensional approach is more suitable. > > > > I do not understand in what sense it is 'multi-demensional'? Can I > assume you mean that OO constructions are single dimensional in some > sense? Just try to build a sub-type-based classification system for people. Not just employees, but *people*. (The same issues happen for "employees", but under "people" it is more obvious.) -T- |