Re: Article about GNU Guile and GOOPS

[Panicz Maciej Godek]

Hello everybody,

2014-03-04 13:57 GMT+01:00 Jan Wedekind <address@hidden>:
[...]
>   It took me a while to figure out defining constructors and dynamic
> instantiation of OO primitives. I hope it'll save somebody else some time
> one day.

Well, I think that I'm a similar case -- it also took me a while how
to define constructors. Perhaps patching a GOOPS manual would be a
more effective solution.

>   Any comments and suggestions are welcome.

I'm really glad that the topic has finally been touched. However, I
didn't find the metaclass part particularly useful -- I think it would
be more valuable, if there were some real-life applications of
metaclasses presented, or if there was just a link to the proper
section of the GOOPS manual instead of the whole section on
metaclasses (because it doens't make the text any clearer).

What I find lacking is a criticism, or at least some reference to the
more contemporary approaches to OOP (such as Ruby or Python or Java).

I have been using GOOPS quite extensively, and I personally find it a
little controversial. For one, because there's no standard and
portable OOP framework for Scheme. This lack of portability is of a
big concern to me.

Besides, I think that Scheme + OOP has its own flaws. In most OOP
languages, you have this notation object.property or object->method(),
which also allows for chain calls, i.e. object->getChild()->method(),
or -- if you have nested objects -- to use
object.property.propertys_property.

If you want to obtain a uniform access to slots (i.e. without the
#:getter and #:setter -- which are a surprising way of introducing new
definitions to a module), you need to use slot-ref and slot-set!. This
quickly becomes horrible when you have nested calls:
(slot-ref (slot-ref object 'property) 'propertys-property)
[The same applies to vectors, arrays, hash tables and other stuff].
I managed to create a workaround (using the GOOPS multi-method
dispatch, read-hash-extend and procedure-with-setter) that allows me
to write
#[object 'property]
and
#[object : 'property : 'propertys-property]
(it also supports vectors and hashes and so on) and although it helps
a little, I'm not particularly happy with that solution.
It is available here, if anyone's interested:

http://hg.gnu.org.ua/hgweb/slayer/file/d5302c97b90d/guile-modules/extra/ref.scm

2014-03-04 15:03 GMT+01:00 Thompson, David <address@hidden>:
[...]
>
> 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."

On the contrary, I'm actually rather unhappy that you need functions
like hash-for-each or vector-map or string-append in order to express
a single concept. (To be honest, I hope that one day explicit hash
tables, strings and vectors would disappear from Scheme, and there'll
only be lists, because they bring nothing new conceptually and are
there only for sake of efficiency)

> 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.
>
> WDYT?

I think that it is different in that JavaScript's addition operator
performs an implicit cast, while CLOS-alike methods allow you to
specialize your function for various types of arguments, so you'll
simply get an error if you don't implement "+" for <number> and
<string>.
And although it might seem a little bit risky, I like to have the
option of using the same name for different concepts and still have a
system behave reasonably, because that's basically how natural
language works (which is full of homonyms, like "like"). On the other
hand, I have to admit that the module system in Guile is excellent at
separating concepts from different domains, even if their names are
the same.

What I find more disturbing is that there is no possibility to specify
a type for a particular slot, but this is a broader topic.

regards