1 2 Previous Next 21 Replies Latest reply on Mar 14, 2013 4:21 PM by jschellSomeoneStoleMyAlias Go to original post
      • 15. Re: in OOP - should there be two types of classes ?
        Sir you first learn the pattern of Singleton , or start a new thread for singleton pattern if you really want to learn the singleton pattern , or search internet wisely and efficiently to learn it. do not start your wrong coding here in this post . please .
        • 16. Re: in OOP - should there be two types of classes ?
          So since you cannot convince anyone you're now just going to be insulting and abusive huh?
          • 17. Re: in OOP - should there be two types of classes ?
            I am not insulting anyone , i was just replying to someone who is "assessing skills" of people , which is not righteous. If a person has a capability to discuss the point then he should not talk about the ability of a person or skill of a person.
            No body should criticise personally in a blog or post , if they can not make their ideas understood other people.
            Last post started , assessing skill and talking about the abilities of a person , that is why i had to write that , otherwise i was doing discussion wisely and softly.
            • 18. Re: in OOP - should there be two types of classes ?
              syparth wrote:
              neither I am interested in your singleton code copied from somewhere.
              Ouch, that hurt! ;)
              wisely read the whole post instead of the last one , then comment .
              I did read the whole thread, unfortunately. You're not making much sense, and you were the one who was going on about singletons.
              • 19. Re: in OOP - should there be two types of classes ?
                Thank you very much to all of you for inputs.
                Thanks for suggestion of posting this point in to Java Community Process , well , hopefully I should get something better.
                Wish me for better luck instead ;)
                • 20. Re: in OOP - should there be two types of classes ?
                  Am not sure , why you want to limit the OOP language with limited keywords and concepts.
                  I like OOP theory, and Java, they way they are. You're the one who wants to change them. Make your case. And make up your mind. Are you talking about OOP theory, as per your title, or the Java language, or the Java OOP language, or all OOP languages? It's very difficult to follow your train of thought, assuming there is one.
                  To make a note on a class weather it is a simple class or singleton class you would sit to read the whole javadoc?
                  That's what I've been doing for quite a while, yes. It's not difficult, and it's certainly not the problem you are making it out to be.
                  or emphasize the programmer to write specifically "singleton" word in his rehtorical javadoc?
                  I don't know what you mean by 'rhetorical' here. I don't think you do either. Stick to the point.
                  the programmer might use other terminology in javadoc instead of "singleton" word. Why you want to make such things so much messy?
                  You've got it wrong again. I'm not the one who wants to introduce a new keyword for every design pattern, new or old. You're the one who's advocating that. Any resulting mess is your responsibility. If you want to claim the existing situation is messy, you're welcome, but that's not a reason to indulge yourself in illogical and infeasible proposals to change the world in incompatible ways. If you knew more about the theory of computation than you evidently do, you would know that the quest for consistency and completeness was exploded permanently in 1931. The world is messy. Programming languages are messy. People are messy. Just accept it. We can control it. We can't eliminate it. It's been tried. Forget it.
                  Instead of allowing Java to introduce a keyword and concept "Singleton class " ?
                  And Factory, and Abstract Factory, and Visitor, and Facade, and Bridge, and Decorator, and a total of 23 in the original Design Patterns book, and several hundred more that were added in the DP frenzy of the late 1990s, and no doubt new ones every day. When do we stop? You have completely failed to address this point, although I have now reiterated it several times. There is also the issue that many design patterns extend over multiple classes or indeed multiple systems and can't be dealt with by merely adding single keywords to a single class. In any case contrary to your apparent fixation, adding keywords to a language is not the end of all wisdom. If, again, you knew more about the history of computing than you evidently do, you would know that the ANSI committee was nearly sued over the introduction of about 400 keywords into COBOL-8X. This is very far from being a trivial concern, and it is not one you are going to get resolved by posting in a mere forum.
                  Just to save the alphabetical keyword parsing of Java language ?
                  Don't put words into my mouth. Nobody has said any such thing. If you knew anything about compiling, which you also clearly don't, you would know that adding keywords to the parser is an extremely minor concern for a compiler writer. The important point is what do the keywords mean. In all the cases both you and I have mentioned, the answer is 'absolutely nothing'. The keywords you seem to be asking for have no semantic effect whatsoever on the compiler. They are merely decorative: and therefore redundant. They are annotations, or Javadoc, and guess what, we already have those.
                  This argument does not make a sense even for concepts which are highly adopted in the programming.
                  This statement does not even begin to make sense, and it certainly does not address the point you pretend to be answering in any way.
                  You might not be aware of it or might be ignoriing it.
                  Or I might be aware of 'it', or I might not be ignoring 'it', or 'it' might be nothing to ignore in the first place, or several other possibilities, none of which are relevant. It's up to you to make your case. You haven't done so, and you haven't addressed any of the objections that have been raised.
                  have you realized the singleton concept
                  I know what a singleton is. I also know that a class being a singleton has zero semantic effect on the compiler, and is therefore not something the compiler needs to know about. When you've written a couple of compilers, so you are competent to debate that, come back. At present you're talking when you should be listening.
                  singletons are limited to single objects
                  Thanks for the history lesson, but I read the book when it came out, over 18 years ago. You don't need to instruct me on design patterns, or about anything else you've raised in this thread. What you need to do is sit down, think, and ask yourself what your chances of getting dozens of insignificant and semantically empty keywords added to the Java programming language really are, which is zero; and then ask yourself why that is so. Ask yourself what the compiler would do differently if it saw the keyword 'singleton', which is nothing; and then ask yourself why anybody including yourself should even consider the whole discussion as anything but a complete waste of time.
                  • 21. Re: in OOP - should there be two types of classes ?
                    syparth wrote:
                    Let me take an example and convey you , please do not tear the sentences , read the post as whole , and please do not get baffled looking at "capital letters " in keyword , please go through the concepts only .
                    Take one example in programming patterns - "Singleton" pattern.
                    Why do we need Singleton pattern ? because we do not need any more object of a class. So such class defines something different than other classes which defines the worldly objects' concepts.
                    If you want to check wheather the class is Singleton or normal you have to gone through many parts of the class - like you said in your last post - "you will look at lots of things of the class ".
                    A normal class and a Singleton class , both are too much different concept wise .
                    I am pointing to these concepts , that the "class" is too much generalized concept. It needs specialization concepts in OOP or OOP language.
                    Based on your analogy houses should be built from houses, grocery stores from grocery stores, etc.

                    But they are not. They are built from nails, concrete, wood, etc.

                    OO languages are used to construct OO applications. The language itself does not represent an OO application.

                    And 'class' exists for the same reason nails exist - as a tool to build something.
                    1 2 Previous Next