Re: A couple of questions about goops method parameters

[David Thompson <dthompson2@worcester.edu>]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> 2014-09-05 21:12 GMT+02:00 David Thompson <dthompson2@worcester.edu>:
>> Panicz Maciej Godek <godek.maciek@gmail.com> 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?
>>
>> http://elm-lang.org/learn/What-is-FRP.elm
>>
>> 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 - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate