Like Tree14Likes

Just Beginning

This is a discussion on Just Beginning within the General Discussions forums, part of the Community Boards category; Originally Posted by oogabooga A "method" is an action that an object knows how to do to itself. A "function" ...

  1. #16
    Registered User
    Join Date
    Oct 2006
    Posts
    2,154
    Quote Originally Posted by oogabooga View Post
    A "method" is an action that an object knows how to do to itself.

    A "function" is an action that knows how to do something to an object.
    I mostly agree on the first part, but on the second, I see it a quite bit differently.

    From my perspective, I see a method as an operation that performs a task and returns no value, aside from indicating success or failure. I've always seen a function, in the context of an object, as an operation that may perform a task, but also definitely returns a value other than success or failure. I suppose that view of things may come from mathematics, where a function is defined as a mathematical operation that produces an output value, given a set of inputs. in mathematics, that output is always deteministic, but a function in a program need not be.

    consider the following c++ class:
    Code:
    class dog
    {
      public:
        void bark();
        int getAge();
    };
    in my example, I would call dog::bark() a method, but I would call dog::getAge() a function.

  2. #17
    Registered User
    Join Date
    Sep 2008
    Location
    Toronto, Canada
    Posts
    1,831
    Not meant to be flamebait. Just venting.
    I only spoke from personal experiences with C++ and Objective-C (under Apple’s Cocoa API).
    True I can not wrap my head around it.

    I’m certainly not trying to discourage anyone from learning other languages. I am not ignoring other programming languages, Elysia. I do have a broader perspective, laserlight. I have learned various assemblers, Pascal, SNOBOL, PL/C, Lisp, COBOL, APL, BASIC, Visual Basic, TAL (Tandem Application Language).
    It’s just that any OOP makes my brain melt. That’s my personal view, backed by several failed attempts to learn it.
    To me abstractifying is like painting a hammer pink and wrapping it in foam so it won’t be quite so hammery. And all the “advantages” that comes with.

  3. #18
    Registered User
    Join Date
    Oct 2006
    Posts
    2,154
    Quote Originally Posted by nonoob View Post
    To me abstractifying is like painting a hammer pink and wrapping it in foam so it won’t be quite so hammery. And all the “advantages” that comes with.
    the point of abstraction is to benefit the programmer, and is not a concept that is exclusive to OOP. the point is to hide the details of the implementation, so that the programmer need only be concerned with the interface. this can be accomplished in nearly any language, and I'd consider it good practice, no matter what language you use.

    your example of the hammer is not a good example, because abstraction is not about making the hammer less "hammery," but rather to make programmer less concerned about exactly what type of hammer he is dealing with. it could be a general carpentry hammer, or it could be a 10lb sledge, or it could even be an axe. when you say swing_hammer(myHammer) in C, or myHammer.Swing() in C++, you don't need to know the details of how that swing happens, only that you are swinging a hammer. that is abstraction.

  4. #19
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    3,832
    To me abstractifying is like painting a hammer pink and wrapping it in foam so it won’t be quite so hammery. And all the “advantages” that comes with.
    O_o

    A related analogy by someone endlessly fascinated by the POSIX view of transmission and communication: "abstractifying" (a nice word) is like the process of painting all hammers pink because we don't care which brand we use so long as we have a pink hammer.

    Soma
    Elkvis and Yarin like this.

  5. #20
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,532
    Maybe a construction company wants to publicly acknowledge breast cancer awareness month. You just don't know when you might need a pink hammer.
    laserlight likes this.

  6. #21
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    3,832
    O_o

    The flamboyant construction worker next door has been eying my pink hammer all day.

    [Edit]
    If it is any consolation at this point, I do feel bad for saying that out loud.
    [/Edit]

    Soma

  7. #22
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,185
    Quote Originally Posted by nonoob View Post
    Not meant to be flamebait. Just venting.
    I only spoke from personal experiences with C++ and Objective-C (under Apple’s Cocoa API).
    True I can not wrap my head around it.

    I’m certainly not trying to discourage anyone from learning other languages. I am not ignoring other programming languages, Elysia. I do have a broader perspective, laserlight. I have learned various assemblers, Pascal, SNOBOL, PL/C, Lisp, COBOL, APL, BASIC, Visual Basic, TAL (Tandem Application Language).
    It’s just that any OOP makes my brain melt. That’s my personal view, backed by several failed attempts to learn it.
    To me abstractifying is like painting a hammer pink and wrapping it in foam so it won’t be quite so hammery. And all the “advantages” that comes with.
    Fair enough. If that is the case, then I retract my comment.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  8. #23
    Registered User
    Join Date
    May 2012
    Posts
    1,066
    Quote Originally Posted by Elkvis View Post
    From my perspective, I see a method as an operation that performs a task and returns no value, aside from indicating success or failure. I've always seen a function, in the context of an object, as an operation that may perform a task, but also definitely returns a value other than success or failure. I suppose that view of things may come from mathematics, where a function is defined as a mathematical operation that produces an output value, given a set of inputs. in mathematics, that output is always deteministic, but a function in a program need not be.

    consider the following c++ class:
    Code:
    class dog
    {
      public:
        void bark();
        int getAge();
    };
    in my example, I would call dog::bark() a method, but I would call dog::getAge() a function.
    The distinction you describe (having a return value or not) is commonly known as the distinction between procedures (no return value) and functions (return value) in some languages.

    Quote Originally Posted by Wikipedia
    Some programming languages, such as Visual Basic .NET, Pascal, Fortran, and Ada, distinguish between functions or function subprograms, which provide an explicit return value to the calling program, and subroutines or procedures, which do not. In those languages, function calls are normally embedded in expressions (e.g., a sqrt function may be called as y = z + sqrt(x)); whereas procedure calls behave syntactically as statements (e.g., a print procedure may be called as if x > 0 then print(x). Other languages, such as C and Lisp, do not make this distinction, and treat those terms as synonymous.
    Subroutine - Wikipedia, the free encyclopedia
    But method is a pretty well defined term for a subroutine of a class in OOP and there's usually no distinction whether it has a return value or not.

    Bye, Andreas

  9. #24
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,534
    Quote Originally Posted by whiteflags View Post
    Well, I don't know etymology, but the usage certainly does make sense. Consider the following:

    Methods

    The way I think of it, we all have methods, or ways of doing things people ask us to do.

    I have to admit, I found this browsing wikipedia. Wikipedia is a great way to find the random blogs it is frequently sourced with.
    But that's the problem. A method is a _way_ of doing something. But in OOP a "method" still just fulfils a request in the same way any old function would. Any function, whether or not a "method" may go about preforming it's request in a particular way.

    I'm just not seeing how datum.proc() is somehow more methodic than proc(datum).
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  10. #25
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,534
    Quote Originally Posted by nonoob View Post
    To me abstractifying is like painting a hammer pink and wrapping it in foam so it won’t be quite so hammery. And all the “advantages” that comes with.
    If abstractification isn't advantageous, why are you coding in C, rather than assembly? After all, from experience, I can tell you that asm is way more hammery than C.
    Elkvis likes this.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  11. #26
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,532
    Quote Originally Posted by Yarin View Post
    But that's the problem. A method is a _way_ of doing something. But in OOP a "method" still just fulfils a request in the same way any old function would. Any function, whether or not a "method" may go about preforming it's request in a particular way.

    I'm just not seeing how datum.proc() is somehow more methodic than proc(datum).
    obj.proc() isn't more OOP-like than proc(obj). In python I think you can do it either way. But methods are supposed to be associated with classes.

  12. #27
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    3,832
    I'm just not seeing how datum.proc() is somehow more methodic than proc(datum).
    O_o

    This always upsets me.

    I think this is why otherwise intelligent people who already use every "tool" in the "OOP" umbrella fail to understand languages called "OOP" or whatever. (I'm willing to be that nonoob loves abstractions and uses them constantly. He just doesn't like the C++ approach.)

    Canonical code is one thing; I can't write canonical Perl to save my soul. I write C using Perl.

    That is not a failure of mine in understanding Perl syntax. (Unless you are a Perl purist in which case bite me.) I understand Perl syntax perfectly fine; I just don't like the "sins" of Perl.

    That's the thing though; every language ever is just sin and syntax.

    There is not a dimes worth of difference between those two expressions from a purely semantic standpoint. It all just comes down to what "sins" the language commits or makes the programmer commit.

    In C++ the first expression implies more than the second because of the "sins" of C++; without knowing the details of the code we can't say the expression is more or less "OOP" than the other expression. It again comes down to the "sins" of the language and how well the programmer understands canonical code (and so the "sins").

    TL;DR: Don't let fools who have completely eliminated all reason from terms like "OOP" scare you off of using valuable tools.

    After all, from experience, I can tell you that asm is way more hammery than C.
    ^_^

    Well yeah, but it takes like a million lines of assembler to paint a hammer pink.

    Soma
    whiteflags and Elkvis like this.

  13. #28
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,534
    Quote Originally Posted by whiteflags View Post
    obj.proc() isn't more OOP-like than proc(obj). In python I think you can do it either way. But methods are supposed to be associated with classes.
    Quote Originally Posted by phantomotap View Post
    This always upsets me.

    I think this is why otherwise intelligent people who already use every "tool" in the "OOP" umbrella fail to understand languages called "OOP" or whatever. (I'm willing to be that nonoob loves abstractions and uses them constantly. He just doesn't like the C++ approach.)

    Canonical code is one thing; I can't write canonical Perl to save my soul. I write C using Perl.

    That is not a failure of mine in understanding Perl syntax. (Unless you are a Perl purist in which case bite me.) I understand Perl syntax perfectly fine; I just don't like the "sins" of Perl.

    That's the thing though; every language ever is just sin and syntax.

    There is not a dimes worth of difference between those two expressions from a purely semantic standpoint. It all just comes down to what "sins" the language commits or makes the programmer commit.

    In C++ the first expression implies more than the second because of the "sins" of C++; without knowing the details of the code we can't say the expression is more or less "OOP" than the other expression. It again comes down to the "sins" of the language and how well the programmer understands canonical code (and so the "sins").

    TL;DR: Don't let fools who have completely eliminated all reason from terms like "OOP" scare you off of using valuable tools.

    I'm not talking about what's OOP and what's not.


    I don't understand how a function that lies within an object, is somehow a "method", but any other function isn't. I understand that this term is very established, but that doesn't explain how it came to be. It doesn't make any sense to me.

    Quote Originally Posted by phantomotap View Post
    Well yeah, but it takes like a million lines of assembler to paint a hammer pink.
    More or less my point.
    Last edited by Yarin; 10-10-2012 at 06:21 PM.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  14. #29
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,160
    Quote Originally Posted by Elkvis View Post
    while quite possible, truly learning C, to the point where you can code as proficiently as the big boys (and girls) who implement the linux kernel or gcc, takes many many years. be prepared to eventually (probably sooner rather than later) run into a problem that will make your brain melt, and just know that the regulars on this forum will be here to help you.
    I disagree, sort of. If you look at the source code to the Linux kernel, for instance, you find that nearly all of the code is written using nothing but constructs that are taught to beginners -- in fact, nothing at all in the C language is really that hard to figure out (in my opinion). But knowing the syntax and semantics of C is not really enough to be able to implement anything big. The problem is not that you don't understand the language well enough, it's that you don't understand how to think about something that is incredibly complicated.

    The years of experience give you the ability to maintain large, complex abstractions in your mind and do operations on them. Mostly it is learning how to identify the parts that can be ignored, then ignoring them.

    The language is just how you write down the stuff that you are thinking about.

    EDIT: But maybe I'm too pedantic, and by "C" you mean all of that in addition to the language itself.
    AndiPersti likes this.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  15. #30
    Registered User
    Join Date
    Oct 2006
    Posts
    2,154
    Quote Originally Posted by brewbuck View Post
    and by "C" you mean all of that in addition to the language itself.
    indeed I did. I guess the better way to express it is learning to program in C can be very difficult. the C language itself is not. I learned the language in a very basic way in about 3 weeks when I was in 11th grade. 17 years later, I still don't think I'm any good at programming in C, although I do understand the language. I am most proficient in C++, because that's where I spent the most time. I like the ideas of object orientation, encapsulation, inheritance, and polymorphism - all ideas that are much more difficult to implement in a language (C) that does not natively support them. I also like the raw power of languages that work on the same level as C, which is why it's C++ for me, and not Java or C#, although I do use both of those languages when it is appropriate.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. beginning C#
    By DennChooch in forum C# Programming
    Replies: 7
    Last Post: 11-21-2012, 04:52 AM
  2. Beginning Tutorials
    By Sugar in forum C++ Programming
    Replies: 7
    Last Post: 12-28-2011, 09:37 PM
  3. Beginning ASM.
    By Krak in forum C++ Programming
    Replies: 4
    Last Post: 12-06-2004, 05:27 PM
  4. beginning C++
    By datainjector in forum C++ Programming
    Replies: 2
    Last Post: 12-12-2002, 01:27 AM
  5. In the beginning...
    By CAP in forum Game Programming
    Replies: 21
    Last Post: 05-29-2002, 01:40 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21