 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Meh. Even good old Turbo Pascal had function pointers.
>>
>> O RLY?
>>
>> Because, I was actually *looking* for that feature, and couldn't find
>> it. It would have been quite helpful...
>
> Might depend on the version; I know it was there in 6.0,
I only used 5.5
> because that's
> the one I used when I invented polymorphism (without the use of the OOP
> language extensions; I didn't have the faintest idea what OOP was all
> about, let alone that I was already using one of its core concepts).
Yeah, that's what I was trying to do too. ;-)
I love how 5.5 added "OOP", which consisted of letting you use the
keyword "class" instead of "record", and letting you write your function
code inside a class instead of outside it. I spent ages trying to figure
out what advantage that gives you. And of course... IT DOESN'T. It's no
different. In particular, IT'S NOT OOP.
It would have /actually/ been OO if it had let you make fields private,
or if it supported dynamic binding. But noooo... :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/04/2012 02:41 PM, clipka wrote:
> Am 23.04.2012 12:19, schrieb Invisible:
>> OK, so "magma" consists of a set S and a binary operator #. The #
>> operator takes any two elements of S (including the possibility of two
>> copies of the same element), and yields a new element of S (possibly the
>> same one you started with).
>
> And here I was thinking that magma consisted of molten minerals...
For extra credit, work out the difference between a semigroup and a
groupoid. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.04.2012 12:19, schrieb Invisible:
> A less abstract way to think about it is this: If you have a value like
> x, you can put that inside a "box", which I will denote as [x]. Any
> value can be put in a box; in particular, you can put a /box/ in a box,
> for example [[x]].
I suggest thinking outside the box... (sorry, pun definitely intended).
Call it a wrapper object, and I guess we're fine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/04/2012 02:50 PM, clipka wrote:
> Am 23.04.2012 12:19, schrieb Invisible:
>
>> A less abstract way to think about it is this: If you have a value like
>> x, you can put that inside a "box", which I will denote as [x]. Any
>> value can be put in a box; in particular, you can put a /box/ in a box,
>> for example [[x]].
>
> I suggest thinking outside the box... (sorry, pun definitely intended).
>
> Call it a wrapper object, and I guess we're fine.
Well, "box" is fewer letters to type. ;-)
You can take the guy out of the Haskell, but you cannot take the Haskell
out of the guy. o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.04.2012 15:43, schrieb Invisible:
> I love how 5.5 added "OOP", which consisted of letting you use the
> keyword "class" instead of "record", and letting you write your function
> code inside a class instead of outside it. I spent ages trying to figure
> out what advantage that gives you. And of course... IT DOESN'T. It's no
> different. In particular, IT'S NOT OOP.
>
> It would have /actually/ been OO if it had let you make fields private,
> or if it supported dynamic binding. But noooo... :-P
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.
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.
BTW, I'm not sure whether they added any new syntax features to classes
from 5.5 to 6.0, but AFAIR 6.0 *did* support polymorphism; I think the
"Turbo Vision" framework made excessive use of it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It would have /actually/ been OO if it had let you make fields private,
>> or if it supported dynamic binding. But noooo... :-P
>
> 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.
It came out around the time OOP was the latest crazy, and everything
that wasn't OO was old and obsolete, and OO was the wave of the future.
So they took the existing language, bolted on a few very superficially
OO syntax elements, and said "Hey! Look! Our product is OO now! BUY IT!!"
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.
> BTW, I'm not sure whether they added any new syntax features to classes
> from 5.5 to 6.0, but AFAIR 6.0 *did* support polymorphism; I think the
> "Turbo Vision" framework made excessive use of it.
I gather Turbo Pascal eventually went on to become Delphi, which was
briefly very successful. I believe that really was a full OO system.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> It came out around the time OOP was the latest crazy, and everything
> that wasn't OO was old and obsolete, and OO was the wave of the future.
> So they took the existing language, bolted on a few very superficially
> OO syntax elements, and said "Hey! Look! Our product is OO now! BUY IT!!"
Criticism of the overhyping of object-oriented programming is nothing new.
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...)
> 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
