[Top][All Lists]

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

Re: A couple of questions about goops method parameters

From: David Thompson
Subject: Re: A couple of questions about goops method parameters
Date: Fri, 05 Sep 2014 15:55:28 -0400
User-agent: Notmuch/0.18.1 ( Emacs/24.3.1 (x86_64-pc-linux-gnu)

Panicz Maciej Godek <address@hidden> writes:

> 2014-09-05 21:12 GMT+02:00 David Thompson <address@hidden>:
>> Panicz Maciej Godek <address@hidden> writes:
>>> So perhaps you could tell me how to design a GUI framework in FP and
>>> without OOP. To me it seems that GUI is the main domain the OOP was
>>> crafted for, but if you have some nice functional ideas, perhaps you
>>> could help me to redesign my framework.
>> Are you familiar with functional reactive programming?
>> Using FRP, we can model with mutable state in a pure, functional way.
>> That is, the necessary mutation is hidden behind the runtime of the FRP
>> implementation.
>> Just some food for thought.
> Sure, I've been reading a lot, but I didn't manage to get much of it.
> I mean, the toy examples are really nice, but it's hard for me to see
> the advantage of FRP over OOP in practical systems (e.g. windowed
> applications with buttons and so on). Although I see value in
> encapsulating state mutations, the notion of state seems inevitable in
> describing such applications (like the mere fact that a checkbox can
> be checked or not -- so it's a state which is a part of the
> description).

Yes, it's state, and state will always be there in a realtime
application.  However, you can still model it in a functional way with
procedures that are idempotent and objects that are immutable.  You just
need to glue it all together with something that tracks the current
state of the application.

> BTW I recently ran into a problem with your signal propagation
> framework from (guile 2d). Namely, if a signal is itself a mutable
> object (like a vector or an array), then changing the value of that
> object doesn't propagate (because it happens only when you use
> slot-set!, and not (vector-set! (slot-ref ...)...)).
> I can't find any workaround for that.

I don't consider it a problem because the values stored signals are
intended to be immutable.  I will make that clear when I get around to
documenting things better.  If you mutate an object within the signal
graph, bad things are bound to happen.  The only reasonable side-effects
are those that do not change values stored within signals, like writing
to a log file or playing a sound.  I have intentionally kept mutation at
lowest layer of the system, abstracted away from the user.

David Thompson
Web Developer - Free Software Foundation -
GPG Key: 0FF1D807
Support the FSF:

reply via email to

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