 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> There is no language that "is OOP". OOP is a software design approach;
> An OO language (or OO language feature) is one that helps you implement
> such a design, but nothing more.
Do not confuse the terms "object-oriented programming" (OOP),
"object-oriented design" (OOD) and "object oriented programming language".
OOD is the process of dividing the problem into logical parts,
each part being a class, and establishing their relationships and
dependendcies (inheritance, composition, function calls...) This is
a language-agnostic process.
OOP is the process of implementing that design in an actual language,
of actually writing code.
An object-oriented language is a programming language that supports
the necessary features for OOP natively.
> Bundling record data and related functions (aka methods) in a single
> thing called "class" does help you write software that makes use of data
> encapsulation (an OOP concept); it doesn't help you with enforcing the
> rules of encapsulation, but it simplifies the syntax by (1)
> automatically passing the ubiquitous "this" pointer, and (2) adding new
> namespaces to avoid naming collisions. As such, it does qualify as an OO
> language feature.
Just because a language offers *some* features that are intrinsic
to object-oriented programming doesn't make the language automatically
an OO language.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> "Hey! Look! Our product is OO now! BUY IT!!"
>
> Criticism of the overhyping of object-oriented programming is nothing new.
It just irks me when people take a concept, produce a superficial
semblance of it, and then claim that as the genuine article. Borland
took the idea of OOP and added some trivial syntactic changes which give
the illusion of extra power, without actually offering any.
> A famous paper named "My cat is object-oriented" was published in 1989.
> (The title is a jab at the fact that anything that claims to be "object-
> oriented" sells better, thus if you are selling your cat...)
Required XKCD quote: http://www.xkcd.com/26/
>> About the only /useful/ thing it actually added was a per-type namespace
>> for methods. What's it, really. You could /already/ group code and data
>> together using modules, so the mere syntactic ability to write one
>> inside the other isn't much of a big deal.
>
> No, what object-oriented programming added was inheritance and
> polymorphism. Modules (complete with member functions, public and
> private sections, module instantiation and references) existed before
> object-oriented programming. What OOP added was inheritance, dynamic
> binding and the ability to handle objects polymorphically.
>
> There are some applications where OOP fits like a glove (eg. GUI
> programming), but in most situations just the modular part of OOP is
> more than enough.
You can write modules in Pascal. The functions within them can be public
or private. The types can also be public or private.
However, if a type is public, its entire internal structure must also be
public. (That includes any types it mentions.) Similarly, any type which
is an argument or result type to a public function must be public.
If they had removed these artificial limitations, that would have been
/far/ more useful than just changing the "record" keyword to "class". :-P
(Indeed, that's what Haskell does: You can make a type public, but keep
its internal structure private. And then only functions in that module
can access the internal structure. And that's how you do encapsulation.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/04/2012 03:37 PM, Warp wrote:
> OOD is the process of dividing the problem into logical parts,
> each part being a class, and establishing their relationships and
> dependendcies (inheritance, composition, function calls...) This is
> a language-agnostic process.
Ah yes... Now I remember back to my days at university, learning about
UML and so forth. Great days. Heh. :-S
At any rate, any language where you literally CANNOT DO runtime binding
strikes me as not being very OO. (As I say, Pascal doesn't even have
function pointers, so it's not like you can fake it yourself. You're
just STUCK...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.04.2012 16:37, schrieb Warp:
> Do not confuse the terms "object-oriented programming" (OOP),
> "object-oriented design" (OOD) and "object oriented programming language".
>
> OOD is the process of dividing the problem into logical parts,
> each part being a class, and establishing their relationships and
> dependendcies (inheritance, composition, function calls...) This is
> a language-agnostic process.
>
> OOP is the process of implementing that design in an actual language,
> of actually writing code.
>
> An object-oriented language is a programming language that supports
> the necessary features for OOP natively.
That would qualify Assembler and C as object-oriented: They both
natively support /all/ features that are really /necessary/ for OOP
(actually for /every/ concept commonly associated with OOP). You /can/
do OOP with plain old ANSI C. (As a matter of fact, C++ started out as a
meta-language to simplify object-oriented programming in C; the very
first C++ compilers actually generated C code.)
I'd say, an object-oriented language is a language that provides
syntactic sugar specifically for OO concepts. Syntactic sugar isn't a
/necessary/ feature for OOP though.
> Just because a language offers *some* features that are intrinsic
> to object-oriented programming doesn't make the language automatically
> an OO language.
Does a language have to provide syntactic sugar for /all/ OO concepts,
in order to claim the label "OO language"? I don't think so. Multiple
inheritance, for instance, is a concept supported by only very few
languages. Interfaces are a concept supported by some, but not by
others. Some languages don't support code inheritance. Virtually no
language supports both static and dynamic inheritance.
So ultimately the question boils down to what consitutes the /minimum/
set of OO concepts a language must provide syntactic sugar for in order
to claim the "OO" label. I don't think such a set exists.
BTW, I just had a look in the 'net: Turbo-Pascal 5.5 /did/ support
virtual methods (and thus, obviously, polymorphism). See
http://edn.embarcadero.com/article/images/20803/TP_55_OOP_Guide.pdf for
more details on TP 5.5's OOP extensions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2012 1:05, Invisible wrote:
>> There are lots of languages that let you can pass a function as an
>> argument.
>
> Heh. I bet most of them are scripting languages though. :-P
Not really. Arguably, even C allows it, C++, C# allows a delegate which is
essentially the same thing, and yes, bunches of interpreted languages.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2012 3:19, Invisible wrote:
> ∃ i ∈ S: ∀ x ∈ S, i # x = x # i = x
.
I must say it cracks me up that you type things like this and also bitch
about HTML entities not being part of XML.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/23/2012 6:50, clipka wrote:
> I suggest thinking outside the box... (sorry, pun definitely intended).
> Call it a wrapper object, and I guess we're fine.
A box is pretty much what everyone calls it. Indeed, languages that do this
without extra syntax are called "autoboxing" languages. :-)
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/04/2012 06:08 AM, Darren New wrote:
> On 4/23/2012 1:05, Invisible wrote:
>>> There are lots of languages that let you can pass a function as an
>>> argument.
>>
>> Heh. I bet most of them are scripting languages though. :-P
>
> Not really. Arguably, even C allows it, C++, C# allows a delegate which
> is essentially the same thing, and yes, bunches of interpreted languages.
C and C++ have function pointers. It's dubious whether functions are
"first class", but certainly you can pass them as arguments.
C# presumably allows /everything/.
Java allows you to use the reflection API to create an object that
represents a function method, and to invoke that method. Alternatively
you can use anonymous inner classes. (The fact that this feature even
/exists/ tells you how badly Java programmers want anonymous functions.)
Pascal? Forget it.
Eiffel? Well, they have "delegates", which are sort-of the same thing.
Come to think of it, I don't actually /know/ any other compiled languages...
Obviously, any random scripting languages supports eval() and so
trivially supports first-class functions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/04/2012 06:13 AM, Darren New wrote:
> On 4/23/2012 3:19, Invisible wrote:
>> ∃ i ∈ S: ∀ x ∈ S, i # x = x # i = x.
>
> I must say it cracks me up that you type things like this and also bitch
> about HTML entities not being part of XML.
How do you think I got access to the symbols in the first place? I wrote
an HTML document with the right entities in it, loaded it into Firefox
and I was then able to copy and paste them into Thunderbird.
Interestingly, when you put non-ASCII characters into an NNTP post, it
actually works. When you write them into an XML document, it fails
horribly. (In fact, not even non-ASCII. The £ symbol tends to go wrong
too...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 23/04/2012 12:19, Invisible a écrit :
> A magma isn't especially interesting by itself. However, if we add the
> rule that # must be /associative/, then we got a "semigroup".
>
> ∀ x, y, z ∈ S, (x # y) # z = x # (y # z).
>
> Already this begins to have interesting mathematical properties. But if
> we add a special /identity element/, we get a "monoid".
>
> ∃ i ∈ S: ∀ x ∈ S, i # x = x # i = x.
>
Hey, not only you added identity element, but you seems to imply also
(but not really) that its also commutative:
∀ x ∈ S, ∀ y ∈ S, x # y = y # x.
So please be more careful for my poor brain and write instead:
∃ i ∈ S: ∀ x ∈ S, i # x = x and x # i = x.
There is commutativity for the identity element, but it is not needed to
be commutative.
> If you now take your monoid and give every element a corresponding
> /inverse element/, then you have a "group".
>
> ∀ x ∈ S, ∃ y ∈ S: x # y = y # x = i.
Your definition of inverse element once again seems to imply general
commutativity, it is not needed.
(I like to think about the Quaternion group (non abelian group of order
8): 1 & -1 are their own inverse, but inverse of i,j,k are same negative
(-i, -j, -k))
Yes, -i.i = i.-i = 1
but i.j = -j.i = k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
