ok what are the rules
-
The Grand Negus wrote:
why shouldn't we offer it?
Because it's free advertising in the lounge, or did you forget already? Who stands to get paid if he actually does decide to use PEP?
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
Because it's free advertising in the lounge, or did you forget already? Who stands to get paid if he actually does decide to use PEP?
It depends, as you should know. If he buys it to use as is, we get $100. But where's the hypocrisy in that? We've never hidden the fact that our product is for sale. And if he decides to develop on top of it, he'll get a copy to work with for free and then he'll sell his product - in that case, he'll benefit financially as well. Finally, if he becomes a full-fledged Omsosian living and working together with us, drinking milk from the same cows and eating corn from the same fields, I really don't think the question applies - except that, again, I see no hypocrisy there.
-
Shog9 wrote:
As you note, i don't give my oven a list of instructions. The processor for cookies is a human, but this can be implied, and the recipe i write out might well have a bigger focus on nouns (ingredients) than verbs (actions performed on them). In fact, recipes traditionally are written with a very few key verbs, interpreted by context: Mix: 1/2 cup milk, 3 egg yolks (beaten) 1/4 cup brown sugar Fold in: 3 egg whites (whipped to soft peaks) Behind this procedural list of instructions, the mechanics of separating eggs, beating the yolks, whipping the whites, the distinction between mixing and folding... is hidden. The differences between measuring milk and brown sugar are assumed to be known by the processor. "measure 1/4 cup brown sugar using brown sugar measuring method" is unnecessary, as the processor knows to use the method appropriate for each ingredient. Polymorphism in action.
I'm not exactly sure of your point here. "Mix 1/2 cup milk, 3 egg yolks (beaten), 1/4 cup brown sugar. Fold in 3 egg whites (whipped to soft peaks)." is valid Plain English code, as it stands. And in Plain English one doesn't have to say "measure 1/4 cup brown sugar using brown sugar measuring method" but simply "measure 1/4 cup brown sugar" because that sentence will dispatch to the routine defined with the header "To measure some brown sugar" or, if that doesn't exist, "To measure some sugar", or if that doesn't exist, "To measure some crystals", etc, while a similar dispatching of liquid measures will also take place. Polymorphism built into the current Plain English compiler.
Shog9 wrote:
Correct me if i'm wrong, but it seems that a big part of your argument against OO has to do with the syntax.
Half right. The syntax, of course, is unnatural and strained. But my first objection was stated in the previous post - verbs don't belong under nouns. If the cookie and oven and bake example didn't make this clear, let's try a more technical one. In Plain English there's a routine to "Convert a number to a string". In objectland, is this "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"? Who knows? More importantly, who cares since the obvious answer was already - and naturally - arrived at in Plain English.
Shog9 wrote:
i don't find the English sentence structure a particularly appealing substitu
The Grand Negus wrote:
Polymorphism built into the current Plain English compiler.
And polymorphism is one of the tenants of OO as well. Indeed, while it is quite useful in a purely procedural language, it is nearly essential in an OO one, as without it you quickly end up with:
The Grand Negus wrote:
"number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"
string var = numberThere's no reason why the assignment operator shouldn't act differently based on context.---- I just want you to be happy; That's my only little wish...
-
The Grand Negus wrote:
Abandon the "object oriented" way of thinking and write the thing, as much as possible (with the language you've chosen), as traditional procedural code.
I challenge you to flex your brain power and show all of us real (not abstract) reasons as to why you think this is the case. And I even double challenge you to do without talking about PEP. Keep in mind. C is my favorite language, and I believe procedural code can be very organized. But, I also believe OOP has many merits and don't hesitate to use it if the project calls for it. So, you have your challenge. Should you take it or leave us up to you, but since you act like an expert in this field I'd wager this would be like falling off a log. Remember, abstract ideas don't count, those are too easily manipulated to serve an agenda.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
I challenge you to flex your brain power and show all of us real (not abstract) reasons as to why you think this is the case. And I even double challenge you to do without talking about PEP. Keep in mind. C is my favorite language, and I believe procedural code can be very organized. But, I also believe OOP has many merits and don't hesitate to use it if the project calls for it. So, you have your challenge. Should you take it or leave us up to you, but since you act like an expert in this field I'd wager this would be like falling off a log. Remember, abstract ideas don't count, those are too easily manipulated to serve an agenda.
How about this argument. We wrote an exceptionally efficient native-code-generating compiler/linker with interface, file manager, dumper, text editor, and wysiwyg page editor using exclusively procedural code and not once during the development did the project suffer from disorganization, unreliability, or unnatural expression and not once during the development were we ever even tempted to think in an object-oriented paradigm. If that doesn't do it for you, I don't think a handful of posts here will help. When I first started teaching database design many years ago, I wrote into my materials an appendix explaining why the hierarchical and network approaches to database management were less desirable. I soon found, however, that once students mastered the simple and obvious relational approach taught in the course, the appendix ceased to be of interest; so I delete it. I think the same thing applies here. If you have a particular example where you think object-oriented thinking works better than a procedural approach, however, I'll be happy to dissect it.
-
An interface, file manager, hexadecimal dumper, text editor, native-code generating compiler, and a wysiwyg page layout facility combined into a single program is not a trivial system. And yet we accomplished it, simply, conveniently, and with remarkably efficiency - both in development and when it runs - without objects. We've created other equally complex systems likewise. The point being that large projects can be managed without resorting to the unnatural forms demanded by the object-oriented approach.
Any approach can be destructive if imposed on a problem to which it doesn’t suit. If you try to see objects where none usefully exist your efforts will end in tears; conversely, if you refuse to see objects when they occur in the problem naturally and intuitively you’ll also have problems. OO isn’t the be all and end all but by the same token militant anti-OO doesn’t seem to me to be the way to go either. A perfect example is C++’s STL; it many ways it isn’t OO: the algorithms are separated from the containers for example. That said the containers themselves are objects, they just don’t include the algorithms.
Steve
-
The Grand Negus wrote:
Polymorphism built into the current Plain English compiler.
And polymorphism is one of the tenants of OO as well. Indeed, while it is quite useful in a purely procedural language, it is nearly essential in an OO one, as without it you quickly end up with:
The Grand Negus wrote:
"number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"
string var = numberThere's no reason why the assignment operator shouldn't act differently based on context.---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
The Grand Negus wrote: Polymorphism built into the current Plain English compiler. And polymorphism is one of the tenants of OO as well. Indeed, while it is quite useful in a purely procedural language, it is nearly essential in an OO one, as without it you quickly end up with: The Grand Negus wrote: "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)" string var = number There's no reason why the assignment operator shouldn't act differently based on context.
Yes, yes. But you've hidden the problem, not solved it. To do the conversion, does the assignment operator call "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"? In other words, where is the conversion function defined? (And please don't say "under the assignment operator object" because there are clearly two different operations here: assignment of a value to a compatible container is not the same thing as the conversion of a value from one representation to another.)
-
Any approach can be destructive if imposed on a problem to which it doesn’t suit. If you try to see objects where none usefully exist your efforts will end in tears; conversely, if you refuse to see objects when they occur in the problem naturally and intuitively you’ll also have problems. OO isn’t the be all and end all but by the same token militant anti-OO doesn’t seem to me to be the way to go either. A perfect example is C++’s STL; it many ways it isn’t OO: the algorithms are separated from the containers for example. That said the containers themselves are objects, they just don’t include the algorithms.
Steve
Stephen Hewitt wrote:
Any approach can be destructive if imposed on a problem to which it doesn’t suit. If you try to see objects where none usefully exist your efforts will end in tears
But the first rule given us by the Father of Object Oriented Programming, Alan Kay, is this: "Everything is an object".
-
Jeremy Falcon wrote:
I challenge you to flex your brain power and show all of us real (not abstract) reasons as to why you think this is the case. And I even double challenge you to do without talking about PEP. Keep in mind. C is my favorite language, and I believe procedural code can be very organized. But, I also believe OOP has many merits and don't hesitate to use it if the project calls for it. So, you have your challenge. Should you take it or leave us up to you, but since you act like an expert in this field I'd wager this would be like falling off a log. Remember, abstract ideas don't count, those are too easily manipulated to serve an agenda.
How about this argument. We wrote an exceptionally efficient native-code-generating compiler/linker with interface, file manager, dumper, text editor, and wysiwyg page editor using exclusively procedural code and not once during the development did the project suffer from disorganization, unreliability, or unnatural expression and not once during the development were we ever even tempted to think in an object-oriented paradigm. If that doesn't do it for you, I don't think a handful of posts here will help. When I first started teaching database design many years ago, I wrote into my materials an appendix explaining why the hierarchical and network approaches to database management were less desirable. I soon found, however, that once students mastered the simple and obvious relational approach taught in the course, the appendix ceased to be of interest; so I delete it. I think the same thing applies here. If you have a particular example where you think object-oriented thinking works better than a procedural approach, however, I'll be happy to dissect it.
i did program in foxpro using procedural approach and i know that i missed oop that time so much yes i build fairly complex programs using it but if had support of oop then it would take much less time so my point is 1) oop saves time 2) easy to debug 3) reduces complexity 4) make code easily understandable 5) and in the process of evolution oop is winning 6) and why is that more people are using oop concepts 7) when every thing is an object how you can escape oop and the big thing do you know why dinosaurs extinct :)
it is good to be important but it is more important to be good
-
i did program in foxpro using procedural approach and i know that i missed oop that time so much yes i build fairly complex programs using it but if had support of oop then it would take much less time so my point is 1) oop saves time 2) easy to debug 3) reduces complexity 4) make code easily understandable 5) and in the process of evolution oop is winning 6) and why is that more people are using oop concepts 7) when every thing is an object how you can escape oop and the big thing do you know why dinosaurs extinct :)
it is good to be important but it is more important to be good
Amar Chaudhary wrote:
i did program in foxpro using procedural approach and i know that i missed oop that time so much yes i build fairly complex programs using it but if had support of oop then it would take much less time so my point is 1) oop saves time 2) easy to debug 3) reduces complexity 4) make code easily understandable 5) and in the process of evolution oop is winning 6) and why is that more people are using oop concepts 7) when every thing is an object how you can escape oop and the big thing do you know why dinosaurs extinct
If your birthdate here is correct, you are about half my age. Which means I remember things - lived through things - that you haven't. I remember, for example, when General Motors was the clear winner in the evolution of the automobile industry, and the thought of a Japanese car on American highways was nothing but a joke. More to the point, however, I remember when the hierarchical/network approach to database was almost universally accepted as the best. In the "process of evolution", as you call it, this approach was not only winning, but had virtually won; it was backed by IBM and every other major player at the time and no one else stood a chance. But then along came Dr. Codd with a five-page paper describing the "spartan simplicity" of his relational approach, and things changed. But not right away. I quote the dedication found in his final book, written some 25 years later: "To fellow pilots and aircrew in the Royal Air Force during World War II and the dons at Oxford. These people were the source of my determination to fight for what I believed was right during the ten or more years in which government, industry, and commerce were strongly opposed to the relational approach to database management." I suspect I'll be writing a similar dedication to my final work 25 years from now. Now regarding the dinosaurs, let me be blunt. Clearly, you're not old enough, nor have you studied enough, to give me an accurate history of trends and events in data processing just 50 years past. So don't go pretending you know what happened thousands of years ago. For all you know, the dinosaurs might have been destroyed in a cataclysmic flood, and evolution wasn't even a factor.
-
Stephen Hewitt wrote:
Any approach can be destructive if imposed on a problem to which it doesn’t suit. If you try to see objects where none usefully exist your efforts will end in tears
But the first rule given us by the Father of Object Oriented Programming, Alan Kay, is this: "Everything is an object".
The Grand Negus wrote:
But the first rule given us by the Father of Object Oriented Programming, Alan Kay, is this: "Everything is an object".
As alluded to in my previous post, you don't have to follow the "rules" slavishly or see the problem filtered through only one padagram. The fact that you need not be a slave to a particular padagram doesn't diminish its usefulness however.
Steve
-
Shog9 wrote:
The Grand Negus wrote: Polymorphism built into the current Plain English compiler. And polymorphism is one of the tenants of OO as well. Indeed, while it is quite useful in a purely procedural language, it is nearly essential in an OO one, as without it you quickly end up with: The Grand Negus wrote: "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)" string var = number There's no reason why the assignment operator shouldn't act differently based on context.
Yes, yes. But you've hidden the problem, not solved it. To do the conversion, does the assignment operator call "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"? In other words, where is the conversion function defined? (And please don't say "under the assignment operator object" because there are clearly two different operations here: assignment of a value to a compatible container is not the same thing as the conversion of a value from one representation to another.)
The Grand Negus wrote:
To do the conversion, does the assignment operator call "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"? In other words, where is the conversion function defined?
Does it matter? This is a concern for the implementation, but why should the programmer wishing to convert a number to a string care about such details? Personally, i wouldn't implement it as a member of either string or number - such status should be reserved for operations clearly in one domain or the other, which a conversion is not. I also feel it's important to distinguish a conversion (which should be reversible with no loss of information if at all possible) and string formatting (which should offer much more control over the output). I strongly feel conversion operators to be a weak spot in OO languages such as Java or C#, and much prefer the C++ design (which offers a rich set of options, including the ability to define a conversion procedure external to any class).
---- I just want you to be happy; That's my only little wish...
-
The Grand Negus wrote:
But the first rule given us by the Father of Object Oriented Programming, Alan Kay, is this: "Everything is an object".
As alluded to in my previous post, you don't have to follow the "rules" slavishly or see the problem filtered through only one padagram. The fact that you need not be a slave to a particular padagram doesn't diminish its usefulness however.
Steve
Stephen Hewitt wrote:
The fact that you need not be a slave to a particular padagram doesn't diminish its usefulness however.
It does if the language you're using, say C#, demands that paradigm. And when the other road is taken - support all paradigms - you end up with a kludge like C++ whose creator admits is "too large for most programmers to master".
-
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
I'll throw in my two cents. First, I don't like the book Code Complete, though I do suggest reading it once in case it has a good idea you haven't thought of. (Like all books on software methodology, it is excessively dogmatic. It's also a little outdated and, unfortunately, does contain some really bad advice; the problem is it's all so jumbled together it's not clear what the good and bad advice is.) Some of my rules: * Know your tools, especially your debugger and how to search MSDN. * Know your APIs. If you're doing C#.NET, spend an hour each day actually reading through the .NET documentation cover-to-cover. The time will come when you will remember that .NET does something that you now don't have to write and you can look it up. * Know your customer. Treat them as they are always right, even if they aren't. * Hire the best UI designers and do truly objective usability testing. (Rigged usability testing is worse than no testing at all.) * Be pragmatic and flexible. No matter how good your design, how well you have implemented your code, how efficient your process has been, you will never have enough time or resources. The day will come when you will spend seemingly endless days hacking your code just to get it to work. You may even find that your design is so fundamentally flawed you have to throw all your hard work away and start over. * Most "Software Engineers" aren't. Most also overestimate their own capabilities and just how hard software development is. * Commercial software takes significantly longer to develop than that destined for in-house use. * Hire a technical writer early and involve them in all engineering and planning meetings. Have them summarize the results and ensure everyone signs off on them. (Okay, I've had this happen precisely once, but the results were very positive.) * Testing should never answer to the same manager and/or technical leads as the developers. * If you have less than five years solid experience in something, you aren't an expert. Don't claim you are. * In conjunction with this, if someone who IS a recognized expert gives you advice in response to a direct question, listen to them. (Don't spend days or even weeks trying to write code for which a single API is already provided in Win32. Yup, had a developer, the same developer, do this to me three times and yes, he once really did spend two weeks before meekly asking me again what the API was.) * Have one person in charge who has a vision of what the product will be and hold them a
-
Stephen Hewitt wrote:
The fact that you need not be a slave to a particular padagram doesn't diminish its usefulness however.
It does if the language you're using, say C#, demands that paradigm. And when the other road is taken - support all paradigms - you end up with a kludge like C++ whose creator admits is "too large for most programmers to master".
I agree with your statement about C#. I'm fond of C++ however. I'll admit I'm biased (as I'm a C++ programmer) but a multi-padagram language like C++ is just what is needed if you're going to use multiple programming padagrams. I don't agree with your statement that, "you end up with a kludge like C++". It is a hard language to master but flexibility has a price and you can make a mess in any language; plain English included. You don't have to use or understand every language feature to use it (the langauge). Many people use C++ without writing template code for example. The longer you use a langauge the more features you tend to use.
Steve
-
Jeremy Falcon wrote:
I challenge you to flex your brain power and show all of us real (not abstract) reasons as to why you think this is the case. And I even double challenge you to do without talking about PEP. Keep in mind. C is my favorite language, and I believe procedural code can be very organized. But, I also believe OOP has many merits and don't hesitate to use it if the project calls for it. So, you have your challenge. Should you take it or leave us up to you, but since you act like an expert in this field I'd wager this would be like falling off a log. Remember, abstract ideas don't count, those are too easily manipulated to serve an agenda.
How about this argument. We wrote an exceptionally efficient native-code-generating compiler/linker with interface, file manager, dumper, text editor, and wysiwyg page editor using exclusively procedural code and not once during the development did the project suffer from disorganization, unreliability, or unnatural expression and not once during the development were we ever even tempted to think in an object-oriented paradigm. If that doesn't do it for you, I don't think a handful of posts here will help. When I first started teaching database design many years ago, I wrote into my materials an appendix explaining why the hierarchical and network approaches to database management were less desirable. I soon found, however, that once students mastered the simple and obvious relational approach taught in the course, the appendix ceased to be of interest; so I delete it. I think the same thing applies here. If you have a particular example where you think object-oriented thinking works better than a procedural approach, however, I'll be happy to dissect it.
The Grand Negus wrote:
How about this argument. We wrote an exceptionally efficient native-code-generating compiler/linker with interface, file manager, dumper, text editor, and wysiwyg page editor using exclusively procedural code and not once during the development did the project suffer from disorganization, unreliability, or unnatural expression and not once during the development were we ever even tempted to think in an object-oriented paradigm. If that doesn't do it for you, I don't think a handful of posts here will help.
You counter Jeremy with this argument, can't you accept his challenge?
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
-
Amar Chaudhary wrote:
i did program in foxpro using procedural approach and i know that i missed oop that time so much yes i build fairly complex programs using it but if had support of oop then it would take much less time so my point is 1) oop saves time 2) easy to debug 3) reduces complexity 4) make code easily understandable 5) and in the process of evolution oop is winning 6) and why is that more people are using oop concepts 7) when every thing is an object how you can escape oop and the big thing do you know why dinosaurs extinct
If your birthdate here is correct, you are about half my age. Which means I remember things - lived through things - that you haven't. I remember, for example, when General Motors was the clear winner in the evolution of the automobile industry, and the thought of a Japanese car on American highways was nothing but a joke. More to the point, however, I remember when the hierarchical/network approach to database was almost universally accepted as the best. In the "process of evolution", as you call it, this approach was not only winning, but had virtually won; it was backed by IBM and every other major player at the time and no one else stood a chance. But then along came Dr. Codd with a five-page paper describing the "spartan simplicity" of his relational approach, and things changed. But not right away. I quote the dedication found in his final book, written some 25 years later: "To fellow pilots and aircrew in the Royal Air Force during World War II and the dons at Oxford. These people were the source of my determination to fight for what I believed was right during the ten or more years in which government, industry, and commerce were strongly opposed to the relational approach to database management." I suspect I'll be writing a similar dedication to my final work 25 years from now. Now regarding the dinosaurs, let me be blunt. Clearly, you're not old enough, nor have you studied enough, to give me an accurate history of trends and events in data processing just 50 years past. So don't go pretending you know what happened thousands of years ago. For all you know, the dinosaurs might have been destroyed in a cataclysmic flood, and evolution wasn't even a factor.
yes you are true that i didn't read or not see as many things as you did but i don't blindly believe what is been said and don't just stick to one thing i am open for changes and not rigid for what i believe i can see things from different perspective and changes my self with time
The Grand Negus wrote:
when General Motors was the clear winner in the evolution of the automobile industry, and the thought of a Japanese car on American highways was nothing but a joke. More to the point, however, I remember when the hierarchical/network approach to database was almost universally accepted as the best. In the "process of evolution", as you call it, this approach was not only winning, but had virtually won; it was backed by IBM and every other major player at the time and no one else stood a chance. But then along came Dr. Codd with a five-page paper describing the "spartan simplicity" of his relational approach, and things changed.
yes that happened but you see a fact that some thing more flexible and some thing new has taken over procedural coding had its own golden but it gets a fair competitor in designing and users got a net tool to work with few user just denied to use the new tool and stick to the older one saying that it will not work ( oop is whatever you say) and some people used them both the difference can be seen it the market the simply procedural languages changes ( implement the concepts of oop ) to survive now dinosaurs do you believe few floods killed them all or it was there inability to change as you are more experienced than me have you heard of ice age humans survived from it any many more disasters by the way we were talking about oop and procedural ok this time my point is the price difference between the two (supporting languages) :)
it is good to be important but it is more important to be good
-
The Grand Negus wrote:
To do the conversion, does the assignment operator call "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"? In other words, where is the conversion function defined?
Does it matter? This is a concern for the implementation, but why should the programmer wishing to convert a number to a string care about such details? Personally, i wouldn't implement it as a member of either string or number - such status should be reserved for operations clearly in one domain or the other, which a conversion is not. I also feel it's important to distinguish a conversion (which should be reversible with no loss of information if at all possible) and string formatting (which should offer much more control over the output). I strongly feel conversion operators to be a weak spot in OO languages such as Java or C#, and much prefer the C++ design (which offers a rich set of options, including the ability to define a conversion procedure external to any class).
---- I just want you to be happy; That's my only little wish...
Shog9 wrote:
Does it matter? This is a concern for the implementation, but why should the programmer wishing to convert a number to a string care about such details?
Because, I thought, we were talking about the guy was implementing the function as well as the guy who uses it. It's easy to make a case for something if you leave out one whole side of the story.
Shog9 wrote:
Personally, i wouldn't implement it as a member of either string or number - such status should be reserved for operations clearly in one domain or the other, which a conversion is not.
Agreed, but the "personally" at the beginning of your sentence supports my point - with objects there's a choice and the "right" answer isn't clear (to all). With Plain English, the question never arises. Furthermore, there are many such operations that are not "clearly in one domain or the other". Is "Write a string on the console" part of the string domain, or the console domain, or both, or neither? How about "Write a string to the printer"? In a true object-oriented language, such operations, if not placed under something, require the addition of "abstract" constructs and additional keywords, etc. But Plain English handles all of these cases, naturally and efficiently, with no additional parts. And the guy with the fewest parts wins, right, Occam?
Shog9 wrote:
I also feel it's important to distinguish a conversion (which should be reversible with no loss of information if at all possible) and string formatting (which should offer much more control over the output).
Okay with us. In the current version of Plain English, we typically use "put" for assignments (with any necessary, implied, reversable conversions); we use the word "convert" otherwise, and underneath the "puts". So "put 3 into a string" will include an automatic call to the appropriate "convert" function; "convert a number to pdf em units given an emsquare number and a font" does the conversion directly. Both statements compile and run as you see them.
Shog9 wrote:
I strongly feel conversion operators to be a weak spot in OO languages such as Java or C#, and much prefer the C++ design (which offers a rich set of options, including the ability to define a conversion procedure external to any class).
As I said in another p
-
Shog9 wrote:
The Grand Negus wrote: Polymorphism built into the current Plain English compiler. And polymorphism is one of the tenants of OO as well. Indeed, while it is quite useful in a purely procedural language, it is nearly essential in an OO one, as without it you quickly end up with: The Grand Negus wrote: "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)" string var = number There's no reason why the assignment operator shouldn't act differently based on context.
Yes, yes. But you've hidden the problem, not solved it. To do the conversion, does the assignment operator call "number.converttostring" or "string.converttonumber" or "abstract.convert(number,string)"? In other words, where is the conversion function defined? (And please don't say "under the assignment operator object" because there are clearly two different operations here: assignment of a value to a compatible container is not the same thing as the conversion of a value from one representation to another.)
By the way: you might get a kick out of this interview with Stroustrup. Lots of grumbling about people who insist on putting everything in a class hierarchy. The C++ Style Sweet Spot[^]:
I've been preaching this song for the better part of 20 years. But people got very keen on putting everything in classes and hierarchies. I've seen the Date problem solved by having a base class Date with some operations on it and the data protected, with utility functions provided by deriving a new class and adding the utility functions. You get really messy systems like that, and there's no reason for having the utility functions in derived classes. You want the utility functions to the side so you can combine them freely. How else do I get your utility functions and my utility functions also? The utility functions you wrote are independent from the ones I wrote, and so they should be independent in the code. If I derive from class Date, and you derive from class Date, a third person won't be able to easily use both of our utility functions, because we have built dependencies in that didn't need to be there. So you can overdo this class hierarchy stuff.
:)
---- I just want you to be happy; That's my only little wish...
-
I agree with your statement about C#. I'm fond of C++ however. I'll admit I'm biased (as I'm a C++ programmer) but a multi-padagram language like C++ is just what is needed if you're going to use multiple programming padagrams. I don't agree with your statement that, "you end up with a kludge like C++". It is a hard language to master but flexibility has a price and you can make a mess in any language; plain English included. You don't have to use or understand every language feature to use it (the langauge). Many people use C++ without writing template code for example. The longer you use a langauge the more features you tend to use.
Steve
-
By the way: you might get a kick out of this interview with Stroustrup. Lots of grumbling about people who insist on putting everything in a class hierarchy. The C++ Style Sweet Spot[^]:
I've been preaching this song for the better part of 20 years. But people got very keen on putting everything in classes and hierarchies. I've seen the Date problem solved by having a base class Date with some operations on it and the data protected, with utility functions provided by deriving a new class and adding the utility functions. You get really messy systems like that, and there's no reason for having the utility functions in derived classes. You want the utility functions to the side so you can combine them freely. How else do I get your utility functions and my utility functions also? The utility functions you wrote are independent from the ones I wrote, and so they should be independent in the code. If I derive from class Date, and you derive from class Date, a third person won't be able to easily use both of our utility functions, because we have built dependencies in that didn't need to be there. So you can overdo this class hierarchy stuff.
:)
---- I just want you to be happy; That's my only little wish...
-
Shog9 wrote:
Does it matter? This is a concern for the implementation, but why should the programmer wishing to convert a number to a string care about such details?
Because, I thought, we were talking about the guy was implementing the function as well as the guy who uses it. It's easy to make a case for something if you leave out one whole side of the story.
Shog9 wrote:
Personally, i wouldn't implement it as a member of either string or number - such status should be reserved for operations clearly in one domain or the other, which a conversion is not.
Agreed, but the "personally" at the beginning of your sentence supports my point - with objects there's a choice and the "right" answer isn't clear (to all). With Plain English, the question never arises. Furthermore, there are many such operations that are not "clearly in one domain or the other". Is "Write a string on the console" part of the string domain, or the console domain, or both, or neither? How about "Write a string to the printer"? In a true object-oriented language, such operations, if not placed under something, require the addition of "abstract" constructs and additional keywords, etc. But Plain English handles all of these cases, naturally and efficiently, with no additional parts. And the guy with the fewest parts wins, right, Occam?
Shog9 wrote:
I also feel it's important to distinguish a conversion (which should be reversible with no loss of information if at all possible) and string formatting (which should offer much more control over the output).
Okay with us. In the current version of Plain English, we typically use "put" for assignments (with any necessary, implied, reversable conversions); we use the word "convert" otherwise, and underneath the "puts". So "put 3 into a string" will include an automatic call to the appropriate "convert" function; "convert a number to pdf em units given an emsquare number and a font" does the conversion directly. Both statements compile and run as you see them.
Shog9 wrote:
I strongly feel conversion operators to be a weak spot in OO languages such as Java or C#, and much prefer the C++ design (which offers a rich set of options, including the ability to define a conversion procedure external to any class).
As I said in another p
The Grand Negus wrote:
Because, I thought, we were talking about the guy was implementing the function as well as the guy who uses it. It's easy to make a case for something if you leave out one whole side of the story.
If we can accept that the conversion be made implicit based on context, then it doesn't matter what the guy implementing it does. He might put the conversion under a class or namespace hierarchy, standalone, or even build it into the compiler as a block of anonymous machine code spit out wherever such a conversion is required. It shouldn't make a bit of difference to the user.
The Grand Negus wrote:
In a true object-oriented language
Ah, well - i've no use for a pure OO language. I'm sure such things are of academic interest, but such constraints do little for me. OO is great in certain areas, for certain tasks... but i've no interest in trying to make everything an object.
---- I just want you to be happy; That's my only little wish...