Just Beginning

[Elkvis]

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:

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.

[nonoob]

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.

[Elkvis]

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.

[phantomotap]

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

[whiteflags]

Maybe a construction company wants to publicly acknowledge breast cancer awareness month. You just don't know when you might need a pink hammer.

[phantomotap]

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

[Elysia]

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.

[AndiPersti]

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:

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.

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

[Yarin]

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).

[Yarin]

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.

[whiteflags]

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.

[phantomotap]

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

[Yarin]

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.

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.

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

More or less my point.

[brewbuck]

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.

[Elkvis]

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.