 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> > 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).
I can't fathom how you are understanding my sentence as meaning the
*exact opposite* of what it's saying.
Assembler and C are precisely *not* OOP languages because they do *not*
have any kind of native support for OOP features. If you want any kind of
object-oriented programming, you'll have to hack those features manually
because the languages themselves offer no support whatsoever.
> You /can/ do OOP with plain old ANSI C.
So what? That doesn't make it an OOP language.
> 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.
I said in my post "do not confuse object-oriented programming with an
object-oriented programming language", and you are doing exactly that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-04-25 04:09, Invisible a écrit :
> 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...)
That's because Thunderbird changed them to UTF-8, because you told it to
do so in the account options dialog box.
...
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
...
On 4/23/2012 3:19, Invisible wrote:
> =E2=88=83 i =E2=88=88 S: =E2=88=80 x =E2=88=88 S, i # x =3D x # i =3D x=
=2E
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> ∃ 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.
A monoid is /defined as/ having a two-sided identity.
Note that it is possible to have more than one left-identity, OR to have
more than one right-identity. But it is impossible to have a
left-identity and a distinct right-identity.
Suppose that
∃ i ∈ S: ∀ x ∈ S, i # x = x
∃ j ∈ S: ∀ x ∈ S, x # j = x
are the left and right identities of #. Now consider the term i#j. By
the first equation, i#j=j. By the second equation i#j=i. Thus we have
that i = j.
> Your definition of inverse element once again seems to imply general
> commutativity, it is not needed.
Again, a group is /defined as/ having two-sided inverses.
If you wish to split hairs, you don't actually need to /insist/ that the
inverses by double-sided; the associativity of # and the existence of a
two-sided inverse i already necessarily implies this fact:
Consider the term
x # y # x
where y is the left-inverse of x. By that assumption, we have
(x # y) # x = i # x
and by the definition of i as the two-sided identity, we have
(x # y) # x = i # x = x
By the assumption of associativity, we have that
(x # y) # x = x # (y # x)
It immediately follows that y # x must be the identity, and hence that y
is ALSO the right-inverse of x. QED.
> (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))
OK, so 1 is the identity element, -i is the inverse of i, -j is the
inverse of j, and -k is the inverse of k.
> Yes, -i.i = i.-i = 1
> but i.j = -j.i = k
That is true - but irrelevant. You just proved that the group is
non-Abelian. We know that. We're discussing the /inverses/ though, and
if you look, we have:
i . -i = 1 = -i . i
j . -j = 1 = -j . j
k . -k = 1 = -k . k
In other words, -i is the TWO-SIDED inverse of i, and so on and so forth
- as I originally asserted.
Every term commutes with the identity and with its own inverse. It might
not commute with anything else, but it does commute with these two
special elements.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
