[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Article about GNU Guile and GOOPS

From: Nala Ginrut
Subject: Re: Article about GNU Guile and GOOPS
Date: Wed, 05 Mar 2014 19:28:00 +0800

> I think it's a nice little introduction to GOOPS.
> I want to discuss this particular point from the post, because it is
> shared by many other people: "... one thing I don't like about Scheme
> is that there are different function names for each type of arguments.
> E.g. adding numbers is done with +, adding lists is done with append,
> and adding strings is done with string-append."
> Having spent many years now working with object oriented programming
> languages, I hold the opposite opinion.  I think it's awkward to have
> a single '+' operator for all sorts of different operations on many
> different types.  Adding numbers is different than concatenating
> strings or lists and using the same symbol for them leads to
> confusion.  Look at JavaScript for all of the crazy things that happen
> when you add together different types of data: The expression 1 +
> "foo" returns "1foo"!  [] + {} returns "[object Object]"! WTF?  Ruby
> tends to be a bit more sane in this regard, but I think the point
> still stands that operator overloading leads to confusion and strange
> behavior.

Agreed, how about "1"+"2" == "12"
I think it's illogical to understand such a program. Of course, this
equation is too simple, my intention is to explain why a unified method
for various objects looks ridiculous. 
But sometimes we do need a generic way to handle various objects with
hiding the details. There're several ways for this purpose in Scheme to
abstract higher data-representation in some well known approaches. So
one may design a generic function to handle various objects well.
This topic was discussed profoundly in Chapter 2 of SICP, so I don't nag
anymore. ;-)
My opinion is that we don't have to pick the tools from OOP. But some
people may argue that these approaches are actually building a
half-baked OO-system in your code. 

After using GOOPS for a while, I begin to think why we need OO, but I
can't get a conclusion so far. I'm not saying GOOPS is worthless. I want
to raise a discussion about "Is OO necessary for Scheme?"

In spite of generic functions I've mentioned above, there's also
lambda*, which could be both treated as solution for polymorphism. I
realized that we don't need the classical Class too. Because the
record-type in R6Rs is more powerful, it even supports inheritance!
Encapsulation? Maybe the only problem is that we don't have strictly
private symbols, which means there's always a way to touch un-exported
symbols from modules.
But we can specify immutable fields in R6Rs type-record, which can
protect the value. My understanding is that people don't really want to
make a field hidden, they just don't want it to be changed occasionally,
so we don't need strictly private feature, no? 
I confess there's an exception if you want to modify the immutable field
from a 'friend type-record' just like 'friend class', and prevent
others. But I don't know the code context why people need it.

I guess most of the essentials of OOP are covered. I'd like to hear
comments from folks. ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]